Email list hosting service & mailing list manager

Announcement Loop Facility Marc Nieper-Wißkirchen (16 Aug 2022 08:31 UTC)
Re: Announcement Loop Facility Lassi Kortela (16 Aug 2022 09:03 UTC)
Re: Announcement Loop Facility Vladimir Nikishkin (16 Aug 2022 09:24 UTC)
Re: Announcement Loop Facility Marc Nieper-Wißkirchen (16 Aug 2022 09:43 UTC)
Re: Announcement Loop Facility Marc Nieper-Wißkirchen (16 Aug 2022 10:01 UTC)
Re: Announcement Loop Facility Ricardo G. Herdt (16 Aug 2022 10:04 UTC)
Re: Announcement Loop Facility Lassi Kortela (16 Aug 2022 10:17 UTC)
Re: Announcement Loop Facility Ricardo G. Herdt (16 Aug 2022 10:22 UTC)
Re: Announcement Loop Facility Marc Nieper-Wißkirchen (16 Aug 2022 10:39 UTC)
Name of the loop macro Lassi Kortela (16 Aug 2022 10:55 UTC)
Re: Name of the loop macro John Cowan (16 Aug 2022 11:03 UTC)
Re: Name of the loop macro Jakub T. Jankiewicz (16 Aug 2022 11:18 UTC)
Re: Name of the loop macro Marc Nieper-Wißkirchen (16 Aug 2022 11:25 UTC)
Changing the binding of quote et.al. Lassi Kortela (16 Aug 2022 11:46 UTC)
Re: Name of the loop macro John Cowan (16 Aug 2022 11:57 UTC)
Re: Name of the loop macro Marc Nieper-Wißkirchen (16 Aug 2022 12:33 UTC)
Re: Name of the loop macro Marc Nieper-Wißkirchen (16 Aug 2022 11:16 UTC)

Re: Announcement Loop Facility Vladimir Nikishkin 16 Aug 2022 09:24 UTC

Not to nag in the name of nagging, but wouldn't it be nice to finish srfi-226?

On Tue, 16 Aug 2022 at 17:04, Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> > a SRFI specifying an extensible loop facility, inspired by Common
> > Lisp's loop facility, Emacs' cl-loop, and Taylor R. Campbell's
> > implementation of foof-loop.
>
> The fundamental problem with CL loop is that it ties together three
> orthogonal things in such a way that they cannot be pulled apart:
>
> (1) looping combinators
>
> (2) a non-nested style for binding/executing Lisp forms sequentially
>
> (3) a parenthesis-free, SQL-like notation for (2)
>
> Feature (1) is a very good fit for Lisp / functional programming and is
> nice to have.
>
> One of Lisp's best features is that scopes are clearly indicated by
> nesting: (let ((foo ...)) (let ((bar ...)) etc...)). Feature (2)
> flattens the nesting, which makes the scoping harder to understand and
> is non-lispy. This is especially problematic when part of a macro
> expansion. However, Lisp already has let* which does a similar thing.
>
> Feature (3) essentially embeds an ALGOL/SQL style sublanguage into Lisp.
> That's something one can do, but IMHO is so un-lispy that it's unfit for
> inclusion in a Lisp standard. And in CL loop's case, this sublanguage is
> not a general notation but is restricted to a few built-in looping
> constructs: it is used only to implement (1) and (2) and cannot be
> leveraged by CL users for general purpose programming.
>
> foof-loop looks much cleaner than CL loop. It has (1) and (2) but not (3).
>
> IMHO the following is the ideal breakdown of the problem for
> standardization efforts:
>
> (1) is unquestionably useful and probably not very controversial.
>
> (2) should be treated with caution. Nesting should be flattened in a way
> that is as symmetrical to let* as possible.
>
> (3) should be off the table; that problem should be relegated to one of
> the many infix Lisp efforts, and should be a general-purpose syntax, not
> just for looping.

--
Yours sincerely, Vladimir Nikishkin
(Sent from GMail web interface.)