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