On 03/12/2013 04:51 PM, David A. Wheeler wrote:
> 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.
>
That makes sense - AmkG also noted how recently they were added.  It
would be great to have a few more examples in the SRFI.
> 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