Re:Modern, functional Common Lisp: myths and best practices
by lispm on Tuesday February 25, 2020 @04:51PM
(#22417870)
For example I see sometimes macros which generate code with compilation quality (speed, ...) declarations for all or parts of their code. Depending on the combination of qualities TCO might be enabled or disabled in code sections.
[ Parent
| on HN ]
Re:Modern, functional Common Lisp: myths and best practices
by nybble41 on Wednesday February 26, 2020 @10:27AM
(#22423779)
If TCO is guaranteed at the language level, as in Scheme, then it will always be enabled regardless of compilation settings. Debug builds are no more tolerant of stack space leaks than release builds. The fact that TCO isn't guaranteed is the problem here.
Re:Modern, functional Common Lisp: myths and best practices
by lispm on Wednesday February 26, 2020 @04:01PM
(#22427272)
> If TCO is guaranteed at the language level, as in Scheme, then it will always be enabled regardless of compilation settings
Re:Modern, functional Common Lisp: myths and best practices
by nybble41 on Wednesday February 26, 2020 @07:17PM
(#22429025)
Your point? The page you linked to specifically says that Kawa only implements a subset of modern Scheme—by which I mean R5RS or later. Early versions of the Scheme language standard didn't require TCO, but all the recent ones do. This doesn't affect the core point that if TCO is guaranteed by the language standard, as in modern Scheme, then it cannot be selectively disabled because doing so would break perfectly compliant code.