[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how useful are collecting lists?




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