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)
|
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