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 Ricardo G. Herdt 16 Aug 2022 10:04 UTC

Out of curiosity, do you plan to call it 'loop'? That will probably
break all my code, I should start renaming my named lets to 'lp' :)

Am 16.08.2022 12:01 schrieb Marc Nieper-Wißkirchen:
> Thank you very much for your comments, Lassi.
>
> Am Di., 16. Aug. 2022 um 11:04 Uhr schrieb Lassi Kortela
> <xxxxxx@lassi.io>:
>>
>> > 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.
>
> Yes, one can say that CL's loop semantics are consistent with let*.
> Sometimes, you don't want the extra indentation.
>
>> 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.
>
> I agree with you here. On the surface, what I am going to specify in
> the upcoming SRFI looks much more like foof-loop than CL's loop
> syntax. Of course, one could write a custom loop control (due to the
> extensibility) that has a SQL-like syntax (as you call it), but none
> of the predefined loop controls will have.
>
>> 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.
>
> CL's loop facility has "and", so the overall structure is like "let"
> expressions nested in an outer "let*". Sometimes, one needs this
> facility.
>
> While, if possible, the syntactic nesting should correspond to lexical
> scoping, this won't be possible in all generality. The whole idea of a
> loop syntax is to be able to put syntactic elements that are
> semantically related near each other in the code.
>
> The following example is a foof-loop one (untested):
>
> (loop ((with i 0 (+ i j))
>           (let j 1)
>           (until (= i 3)))
>
> The updater of "i", which is "(+ i j)" belongs semantically to the
> introduction of "i", but it is evaluated in the lexical scope of the
> loop's body, which contains the binding to "j" as well.
>
>> (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.
>
> Marc