4 ms·

All 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

by enduser 14y ago

All 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 ago
It 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 ago
  How 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 ago
    From 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.

by enduser 14y ago

Locke1689 14y ago

It 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 ago
How 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 ago
  From 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.