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)
|
> So, a way to express a general dependency graph is needed and let the > Scheme interpreter sort out a suitable sequencing. Aha, the syntax is isomorphic to Makefile syntax. > I propose a form like the following one: > > (let-values (((d) (using c > (k c))) > ((a) (f)) > ((c) (using b > (h b))) > ((b) (g))) > <expr>) > > Marc let-using let-values-using > “The purpose of abstracting is not to be vague, but to create a new > semantic level in which one can be absolutely precise.” > ― Edsger W. Dijkstra "A programming language is low level when its programs require attention to the irrelevant." - Perlis :) I'm very much in favor of encoding dependencies precisely, but a robust and convenient implementation probably requires our field to change the standard program representation from trees to graphs. Nevertheless, this is an interesting hack.