ISLisp has an interesting mechanism when it comes to dynamic variables. I
have come to like it, but there is a missing generality.
to define a dynamic variable: (defdynamic variable ...)
to access a dynamic variable: (dynamic variable)
to set a dynamic variable: (setf (dynamic variable) ...)
to bind a dynamic variable: (dynamic-let ((variable ...)) ...)
the latter form seems somewhat gratuitous, since it is not like `fluid-let'
and does the exactly same thing that `let' does, except for the new way to
refer to special variables.
I would prefer something of this sort:
(let* ((variable1 ...)
((dynamic variable2) ...)
(variable3 ...))
...)
i.e., if the `let' and `let*' forms have the grammar
(let ((var form)*) body-form*)
then "var" may be a simple variable name or list whose first element is
`dynamic' and whose second and last is a dynamic variable name.
(this is based on generalized variable binding from the widely available
`letf' macro, but the special nature of `dynamic' makes it somewhat more
restrictive in scope than a fully general `letf' would be.)
comments?
#<Erik 3028318374>
--
suppose we actually were immortal...
what is the opposite of living your life as if every day were your last?
In article <················@arcana.naggum.no> Erik Naggum <····@naggum.no> writes:
en> I would prefer [...] if the `let' and `let*' forms have the
en> grammar
en>
en> (let ((var form)*) body-form*)
en>
en> then "var" may be a simple variable name or list whose first
en> element is `dynamic' and whose second and last is a dynamic
en> variable name.
The idea of discarding dynamic-let special operator sounds appealing.
`Let' generalization is a natural candidate to support dynamic
binding. Unfortunatly, many of us observed that unexperienced
programmers, when exposed to such syntax, tend to be confused, and
expect some dynamic behavioral from lexical variable or vice-versa.
Supposedly, this is due to the extreme difference between dynamic and
lexical variables. Some more experienced programmers question why is
`let' extension needed, since withf somehow supports dynamic binding.
A better way (as simple, but not confusing) to simplify syntax is
indeed to stick dynamic binding to withf, where (just for one value
and without hygienic consederation):
(withf ((access-form val)) . body)
expands to:
`(let ((old-val ,access-form))
(unwind-protect
(progn
(setf ,access-form ,val)
,@body)
(setf ,access-form old-val)))
Withf-ing a dynamic variable could actually expand to a dynamic-let,
in this perspective the dynamic-let is just a dramatic implementation
optimisation (no more unwind-protect), and no longer needs to be
documented. And incidently, withf-ing a lexical variable is clearly
very different from a `let', avoiding the above confusion.
There is a drawback, though: according to the definition above,
withf-ing a dynamic variable requires that there exists a more general
definition for the same variable (either defdynamic or another
dynamic-let -- ooops, withf).
As I understand it, some ISLisp compatible systems could clear this
issue by requiring all dynamic variables to have a defdynamic (good
for tracking dynamic withf-ing typos at compile-time), while some
others may have a more clever withf, and others may prefer exposure of
dynamic-let (less silly and insignificant parenthesis). Bottom line
is that documenting dynamic-let in ISLisp supports all these options,
is simple, and is therefore the most suitable option for
standardization.
en> (this is based on generalized variable binding from the widely
en> available `letf' macro, but the special nature of `dynamic'
en> makes it somewhat more restrictive in scope than a fully general
en> `letf' would be.)
More restrictive? In what sense?
Pierre Parquier
········@ilog.fr