4 ms·
Learning and practicing the full Common Lisp language. It's a big language for a reason: Greenspun's Tenth Rule is true. If you work on sufficiently large progr
by enduser 14y ago
Learning and practicing the full Common Lisp language. It's a big language for a reason: Greenspun's Tenth Rule is true. If you work on sufficiently large programs in other languages, you will reimplement features already present in Common Lisp. Common Lisp is the careful amalgamation of years of extrordinarily expensive research and learning by some of the brightest minds on how to solve some of the hardest problems in computing. Drink from their distilled wisdom.
- Locke1689 14y agoIf you want a more theoretically pure variation you should look at the Racket language group. My variation of Greenspun's Tenth Rule is that Common Lisp contains a reimplementation of Scheme, with some added "features."
- enduser 14y agoEverything in Scheme is there for a theory. Everything in Common Lisp is there for a practical reason. Common Lisp is the result of many smart people--who understood the theory--delivering big software systems and refining the necessary tools into an eminently practical language.
- Locke1689 14y agoOK, what is the practical reason for abandoning constant space tail-call evaluation?
- enduser 14y agoAll major Common Lisp implementations do have constant-space tail-call optimization: http://0branch.com/notes/tco-cl.html http://0branch.com/notes/tco-cl.html It is not required by the spec, presumably to ease compliance in simpler implementations, because Common Lisp provides other iteration constructs missing in Scheme (DO and LOOP) which were preferred over recursion in practice. Edit: It appears that in some exotic cases CMUCL (and maybe SBCL) does not use constant space for tail-calls when it would interfere with the proper relationship with dynamic bindings.
- Locke1689 14y agoIt is not an optimization, it is a different evaluation semantic. If a semantic property of the language is not guaranteed then it should not be relied upon. Thus, it forces you to alter your code to fit the broken semantics.
- enduser 14y agoHow it is not an optimization to implement the evaluation of a given segment of code in a way that uses less memory? My understanding of the historical reasoning is that DO and LOOP are preferred in practice because the conditions of iteration are specified in a more predictable location. By your line of reasoning, one should not rely upon Typed Racket because the functionality is not guaranteed by Scheme or RxRS. Neither should one rely upon SBCL's ability to run circles around Racket; performance is not guaranteed by the Common Lisp standard.
- Locke1689 14y agoFrom the Racket docs: This evaluation behavior is sometimes called tail-call optimization, but it’s not merely an “optimization” in Racket; it’s a guarantee about the way the code will run. More precisely, an expression in tail position with respect to another expression does not take extra computation space over the other expression. And you're right -- typed racket is still in its growing stages. There are a lot of guarantees you don't have.