you should, as all the other lisps are shit at what they do
Name:
Anonymous2013-07-03 3:09
We should take one that's already here and add the basic luxury of stack traces that always show line numbers and file names.
Name:
Anonymous2013-07-03 3:23
I have.
Name:
Anonymous2013-07-03 6:32
I'm still busy designing it in my mind. And really, I believe we can go beyond Lisp.
Name:
Anonymous2013-07-03 6:54
My self-rolled lisp is going to be just as shitty as all the existing ones.
In fact, lisp sucks precisely because of this: instead of writing and sharing code every little numbskull is busy creating his own personal shitty language.
Name:
Anonymous2013-07-03 6:54
I am not a niggerfaggot.
Name:
Anonymous2013-07-03 6:58
>>2
Racket can do much better than this, unrolling the stack interactively so you can see the error without interrupting the execution.
Name:
Anonymous2013-07-03 7:09
>>5
because no lisp is good enough and the world clearly needs a better one. and mine is the better one, obviously.
Name:
Anonymous2013-07-03 7:18
In the same lecture, Tarver suggested that this problem could either be tackled at the industry or the university end, but that tackling the problem at the industry end required a champion with large amounts of capital to invest in Lisp. Tarver instead proposed to tackle the problem at the university end, by modernising Common Lisp in such a way to make it 'future proof' for at least 25 years. His characterisation of an adequate modernisation of Lisp was summarised in ten requirements which Qi was designed to meet. The solution should:
be Lisp compatible—as the most widely used dialect of Lisp, the solution should be written in Common Lisp and run under Common Lisp.
be free for non commercial and educational use.
be compact—programs should not be any longer than the same programs written in Common Lisp
be simple to learn -- Semantics and syntax should be learnable by a child.
be efficient—The solution should generate programs which are at least as fast as their hand-coded Lisp equivalents. In practice, Qi programs have proven to be often faster.[3]
have the characteristics of a modern functional programming language. By these Dr. Tarver includes pattern-directed list handling, static typing, currying, and partial applications.
not be simply a clone of Haskell or ML—this is part of what constitutes 'future proofing' the solution.
be computationally adequate—meaning that the language is 'adequate for the needs of the programmers of the day'. Dr Tarver characterises 'computational adequacy' as 'a large, vague and important notion' and believes that the extension of this concept changes through time. Common Lisp he characterises as 'computationally inadequate' due to the lack of specification for features such as foreign languages interface and graphics. Tarver believes that Qi itself still needs to achieve this goal through the development of standard libraries for graphics, web interfaces and foreign language handling.
be metaprogrammable and customizable—in that the user should be free to program the syntax of the language. To achieve this Qi has both M-expression and S-expression level syntax for all its syntax, as well as an "eval" function that maps M-expressions to S-expressions; which can make it easier to do metaprogramming in Qi than in Lisp. In terms of customization Qi has an explicit "sugar" keyword to allow the user to program the Qi reader to accept custom syntax.
be well documented and theoretically secure—Qi is fully documented, with formal correctness proofs and has a canonical textbook which is also online.[4]