diff options
author | Kaz Kylheku <kaz@kylheku.com> | 2024-02-22 18:52:04 -0800 |
---|---|---|
committer | Kaz Kylheku <kaz@kylheku.com> | 2024-02-22 18:52:04 -0800 |
commit | be9f298350e371823a1dce3c39f54c4a54e25695 (patch) | |
tree | 2fcc56b137f6a051a1b5514ff174841181cf4ef6 | |
parent | 767f4d591b2cbf7ed93dd1602f1e2a59bf8fc5c8 (diff) | |
download | txr-be9f298350e371823a1dce3c39f54c4a54e25695.tar.gz txr-be9f298350e371823a1dce3c39f54c4a54e25695.tar.bz2 txr-be9f298350e371823a1dce3c39f54c4a54e25695.zip |
doc: add rationale about let vs let*.
* txr.1: Add Rationale: section to let and let* clarifying
that the decision to make let parallel is for compatibility
with other dialects like ANSI CL and Elisp.
-rw-r--r-- | txr.1 | 22 |
1 files changed, 22 insertions, 0 deletions
@@ -15276,6 +15276,28 @@ closures, but are captured in delimited continuations. (let (:a nil)) -> error, :a and nil can't be used as variables .brev +.TP* "Rationale:" + +\*(TL follows ANSI Common Lisp in making +.code let +the parallel binding construct, and +.code let* +the sequential one. In that language, the situation exists for historic +reasons: mainly that +.code let +was initially understood as being a macro for an immediately-called +.code lambda +where the parameters come into existence simultaneously, receiving the +evaluated values of all the argument expressions. The need for sequential +binding was recognized later, by which time +.code let +was cemented as a parallel binding construct. +There are very good arguments for, in a new design, using the +.code let +name for the construct which has sequential semantics. +Nevertheless, in this matter, \*(TL remains compatible with dialects like +ANSI CL and Emacs Lisp. + .coNP Operator @ progv .synb .mets (progv < symbols-expr < values-expr << body-form *) |