David Vanderson:
> That makes sense - AmkG also noted how recently they were added.  It
> would be great to have a few more examples in the SRFI.

Sure!  That's a very helpful comment, thanks.  We can certainly do that.

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

Yes, that's right.  Without collecting lists,
those are the only options... and that's the motivation.

We could change the notation, but the changes look ugly.
The obvious alternatives for the notation are:
1. Make the REPL and file syntax different, like Python.
I think this would be a mistake; people often copy-and-paste
from files to the REPL.
2. Don't stop on blank lines, but that change would make
interactive use much less pleasant.

It's really not a problem when the whole sequence fits on a screen.
But when things get long, it starts to get ugly.

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

I've intentionally defined <* to ALWAYS create another open paren.
I think that's easier to understand, and it also makes it really helpful
in short lists.

I haven't worried about the define-in-define case above, because the
long-and-annoying constructs that we've seen so far (as use cases)
always had some sort of list that <*...*> easily mapped to.
Of course, maybe that's a limitation of the use cases we've discussed!

Hmm. If that's a *problem*, one solution without significantly changing
the existing semantics might be to allow <*...*> after ".".  I suspect
such cases would basically just continue a list.  Here's what I have in mind:
define foo(x) . <*
define bar(y)
! y
define baz(z)
! z
! *>
; ==> (define (foo x) (define bar(y) y) (define baz(z) z))

So... does anyone have thoughts about this?  Is this an important case?
If it is, then is this a solution?  Are people running to the exits?
Other thoughts?

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

Okay.  One challenge with rationale #1, which I agree is the more compelling case,
is that it's not obvious there's an issue until the expressions get long.
Short expressions (say, less than 30 lines) aren't compelling;
300-line expressions are compelling.  But reading 300 lines for one example is... tedious.

Just in general, I want to be very parsimonious about adding new constructs.
We should add a relatively few constructs, they should be simple,
and they should solve as many use cases as plausible.  I doubt there will
be perfect agreement on the right number for "few", but if one construct
can do the work of many use cases, making common constructs easy, then
I take that as a good sign.

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

Absolutely!  Heck, I think proposals are basically the whole point
of the SRFI process, it lets us discuss them.  Please post publicly, so others
can comment.

If you could point out the *problems* you're trying to solve with the rewrite,
that'd be especially helpful.

> Thank you for the readable project!

Sure!! And thanks very much for being willing to give feedback.
As I said earlier, I think that's the whole point of the SRFI process.

--- David A. Wheeler