Group Email Manager

login signup
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:43 UTC 
Am Di., 15. Nov. 2022 um 21:36 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> I file improvements like this to let under ‘things we’d do differently if we did Scheme again from scratch, but it’s too late now’.
>
> Personally I’d have three forms: let (which would be what we currently call letrec*), recur (which would be what we currently call named let), and let-syntax (which would be what we currently call letrec-syntax).

This would be an incompatible change (which, under the "from scratch"
assumption, is fine, of course).  But this makes this more radical
proposal different from the addition I proposed here.

> The explosion of near-identical let forms, and the need to nest them sometimes, is a wart, but adding more just creates an xkcd 927 situation.

The let-values form (with a "using" keyword) is a backward-compatible
extension.  In fact, it could help against the "927" situation because
people would only need to learn let-values/let and there would be no
nesting needed anymore.

> > On 15 Nov 2022, at 13:30, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
> >
> > In Scheme, we use the `let' construct when we want our interpreter to
> > perform several independent operations, and we are interested in the
> > return values of these operations.
> >
> > If, on the other hand, the operations depend on the results (let us
> > neglect side effects, which also create dependencies) of previous
> > operations, we use the `let*' construct.
> >
> > Often, however, the most abstract representation of the algorithm we
> > want to code would need a mixture of `let' and `let*' forms.  Consider
> > the following example:
> >
> > (let* ((a (f))
> >        (b (g))
> >        (c (h b))
> >        (d (k c)))
> >  <body>)
> >
> > Here, D depends on C, which depends on B.  So
> >
> > (let ((a (f))
> >       (b (g)))
> >  (let* ((c (h b))
> >          (d (k c)))
> >    <body>))
> >
> > is a rewrite that is closer to the actual dependency graph.  But it is
> > still not an accurate image of the platonic idea.  In particular,
> >
> > (let ((b (g)))
> >  (let* ((c (h b))
> >          (d (k c)))
> >    (let ((a (f)))
> >      <body>)))
> >
> > is a different approximation, which like the other two, still does not
> > capture the idea that the binding to A is independent of the other
> > bindings.
> >
> > So, a way to express a general dependency graph is needed and let the
> > Scheme interpreter sort out a suitable sequencing.
> >
> > 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
> >
> > “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
>