Mark H Weaver:
> I began to try to learn about them by jumping directly to the
> "Specification" section of SRFI-110.  I'm sorry to say that I find that
> section extraordinarily unclear.  Below, I've made notes about the parts
> that I found confusing.

Wow, thanks SO MUCH for your detailed comments.
It's often difficult to see what's unclear to others, especially
when you've been working with it for some time,
so fresh eyes are really appreciated.

> ... The specification should stand on its own to a
> reasonable extent, IMO anyway.

I completely agree.

I just submitted an updated SRFI before I got this email.
That's no problem, though; we can use this information to determine
how to update the NEXT revision :-).

All: I think part of the problem is that we need a "definitions"
section at the beginning of the spec... with, of course, good definitions.

Anyone have good definitions for "term", "parent" "child", or others?

> * When you speak of "traditional abbreviations", you might want to
>   make a suggestion about how to handle additional non-standard
>   abbreviations.  In particular, the abbreviations #', #`, #, and #,@
>   are widely used by the syntax-case macro system.

A fair point.  I didn't include them as requirements because
R7RS drafts (currently draft 9) don't include them, but
some sort of discussion does seem appropriate.

Perhaps something like "An implementation MAY support
additional abbreviations, such as ..." and then listing those four.

--- David A. Wheeler