Email list hosting service & mailing list manager

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 17 Nov 2022 07:48 UTC

Am Do., 17. Nov. 2022 um 02:53 Uhr schrieb Jeremy Steward
<xxxxxx@thatgeoguy.ca>:
>
> On 11/15/22 13:35, Daphne Preston-Kendal wrote:
> > 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).

As long as your compiler is smart enough, already today you can use
letrec* all the time.  (Only for multiple values, you would need a
different binding form; we are still missing letrec*-values...)

> Aside from the first, which is just called |let|, there's really no
> reason there can't be an SRFI that introduces |recur| as some kind of
> looping construct.
>
> named-let is itself a bit of a wart. I use it frequently and I often go
> back to it, but so so so many folks can't wrap their heads around the
> fact that the |let| syntax has at least 3 major interpretations around
> what could be much more clearly expressed with a separate macro.

(let ((var init) ...) body)

is just

(let dummy ((var init) ...) body)

so I don't consider this necessarily as a wart.

> I know it's a bit of a digression on the topic but I also recall Marc is
> working on some kind of looping macro for Scheme. I think I merely want
> to express support that something like |let-values| and also a |recur|
> macro of some kind would be very welcome even if they don't offer much
> over the standard forms.

What do you mean by "something like let-values"?  We already have
let-values, so what would you like to change?

> Eventually if you replace enough uses of let you can retire it :)
>
> > 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.
> >
> >
> > Daphne
>
> Meh, this isn't a new situation in software and I don't think the SRFI
> process is over-burdened by different |let| bike-shedding.

My general comment on these things:

Experimentation shouldn't stop.  And former solutions should prohibit
better solutions.  If three forms are more expressive than one, we
should go with three.  If three forms are as expressive as five forms,
we should just use three.