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)
|
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.