Re: `let' vs `let*' (was: Re: How do I pass a variable defined in a wrapping let, to a lambda?)

[Emanuel Berg]

Jean Louis wrote:

>> As for `let' vs `let*' in theory `let' is parallel and
>> `let*' sequential but in practice `let*' allows references
>> back to its own bindings, so it is recursive `let' if you
>> will, and `let' isn't ...
>
> In the `dlet' discussion, well... I see it so, dlet is
> creating dynamically bound variables, and thus they should
> be available to all variables inside of `dlet"
>
> (dlet ((first-var 1)
>        (second-var first-var))
>    second-var)
>
> second-var should be equal to first var

Well, the discussion can go both ways ...

(defvar first-var)
(setq first-var 0)

(dlet ((first-var 1)
       (second-var first-var))
    (list second-var first-var)) ; (0 1)

> but developer Mattias Engdegård, he changed it for the
> reason that dlet is not dlet*
>
>>   commit b72f88518b89560accf740a4548368863e6238e0
>>   Author: Mattias Engdegård <mattiase@acm.org>
>>   Date:   Sun Aug 1 17:05:48 2021 +0200
>>
>> *     Make dlet work like let, not let*
>>
>> *     Change `dlet` so that it has binding semantics like `let` because that
>> *     is what a user would expect and it allows a corresponding `dlet*` to
>>       be added later should the need arise.  Fortunately the change has no
>>       effect where it is currently used.
>
> That is what user would expect. But that is not what I as
> user expect. And nobody of other users complained on that,
> though the definition of dlet is changed.

If there are `let' and `let*' I think it makes sense with
`dlet' and dlet*, and slet/llet and slet*/llet*.

Don't know how much sense `let' and `let*' do tho.
Maybe someone is working on the/a true parallel `let' as we
speak ... well, keep it then I guess :)

> dlet is described with: Like ‘let’ but using
> dynamic scoping.

Poor docstring. Because `let' can do dynamic/special variables
even under static/lexical scope. Maybe one could get away with
just adding the word ALWAYS somewhere ...

-- 
underground experts united
https://dataswamp.org/~incal