This page is part of the web mail archives of SRFI 110 from before July 7th, 2015. The new archives for SRFI 110 contain all messages, not just those from before July 7th, 2015.
On 03/12/2013 04:51 PM, David A. Wheeler wrote:
That makes sense - AmkG also noted how recently they were added. It would be great to have a few more examples in the SRFI.Collecting lists are the most recent addition to the notation, and were added after sweeten and letterfall were written. So they're unused for simple reason that, at the time, they didn't exist. That said, I could go back to "sweeten" and add a few uses of collecting lists, to show their use in practice. Sounds reasonable enough, at least to demonstrate utility.
The rationale for collecting lists is here: http://srfi.schemers.org/srfi-110/srfi-110.html#collecting-lists The rationale notes two use cases: 1. A long sequence of definitions contained within an initial statement. This situation occurs in many library definition structures such as Scheme R7RS define-library and in some larger data structures. 2. A let-style statement with one or two variables with short initial values.
I think #1 is a decent rationale, and with some experimenting I'm starting to see how collecting lists are useful there. To make sure I understand, it seems like the primary motivation here is the "unintentional blank line" problem:
define foo(x)
define bar(y)
y
define baz(z)
z
This works in a Python script, but not at the REPL. To avoid that
behavior, when using sweet expressions you either have to remove blank
lines:
define foo(x)
define bar(y)
y
define baz(z)
z
Or you must manually insert \\:
define foo(x)
define bar(y)
y
\\
define baz(z)
z
Are those the only options without collecting lists? If so, I can
understand the motivation.
In my examples, define has an implicit begin. In this situation, I'm unsure how to use <*, because it introduces an extra parenthesis. Have you run into this problem?
The second rationale for collecting lists (short multi-value let expressions) seems much less obvious to me, especially since the alternates given in the SRFI don't look particularly annoying. I would suggest reducing the emphasis on it in favor of #1, but am unsure how the SRFI process works. Would you be open to a suggested rewriting of that section?
Thank you for the readable project! Dave