The most general form of let/let* Marc Nieper-Wißkirchen (15 Nov 2022 12:30 UTC)
Re: The most general form of let/let* Lassi Kortela (15 Nov 2022 20:11 UTC)
Re: The most general form of let/let* Lassi Kortela (15 Nov 2022 20:23 UTC)
Re: The most general form of let/let* Marc Nieper-Wißkirchen (15 Nov 2022 20:28 UTC)
Re: The most general form of let/let* John Cowan (15 Nov 2022 20:38 UTC)
Re: The most general form of let/let* Marc Nieper-Wißkirchen (15 Nov 2022 20:48 UTC)
Re: The most general form of let/let* Daphne Preston-Kendal (15 Nov 2022 20:35 UTC)
Re: The most general form of let/let* Marc Nieper-Wißkirchen (15 Nov 2022 20:43 UTC)
Re: The most general form of let/let* Lassi Kortela (16 Nov 2022 08:19 UTC)
Re: The most general form of let/let* Jeremy Steward (17 Nov 2022 01:53 UTC)
Re: The most general form of let/let* Marc Nieper-Wißkirchen (17 Nov 2022 07:49 UTC)
Re: The most general form of let/let* Jeremy Steward (17 Nov 2022 02:11 UTC)
Re: The most general form of let/let* Marc Nieper-Wißkirchen (17 Nov 2022 07:55 UTC)
Re: The most general form of let/let* Lassi Kortela (17 Nov 2022 08:01 UTC)

Re: The most general form of let/let* Marc Nieper-Wißkirchen 15 Nov 2022 20:48 UTC

Am Di., 15. Nov. 2022 um 21:38 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Tue, Nov 15, 2022 at 3:28 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
>> The form I originally proposed is a generalization of let/let* where
>> the compiler figures out the dependencies.  If the graph is not
>> acyclic, it would be an error.
>
>
> The compiler cannot reliably do that.  If v is bound in a wider scope then (let* ((v 0) (v2 v)) ...) means one thing and (let ((v 0) (v2 v)) ...) means something else.

Exactly! And that's why my proposal uses "using":

(let* ((v 0) (v2 v)) ...)

becomes (syntax debatable)

(let ((v 0) (v2 (using (v) v))) ...)

while

(let ((v 0) (v2 v)) ...)

just stays as it is.