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.
Hello all, First of all, I should admit that I have only begun reading about sweet expressions in the last hour or so. I don't yet understand the rules. 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. No doubt, I could find answers to all of these questions by reading the rest of the document more carefully, and/or by reading the website of the Readable Lisp S-expressions Project. However, I don't think I should have to. The specification should stand on its own to a reasonable extent, IMO anyway. [In the list below, "first list", "second list", and "third list" refer to the three numbered lists of rules in the "Basic specification" section.] * "term" is used before it is defined. * The concepts of "parent" and "child" are not defined. * The use of the term "parameter" is confusing. This is a datum reader after all, which deals with "lists", not "parameters". I'd prefer for it to describe more clearly what data structure is created. * Item 1 (first list): What is an "indented line"? Does that mean any line with non-empty indentation, or does it mean "indented more than some other line"? If the latter, which other line? * Item 3 (first list): Does "multiple terms" mean "multiple terms on the same line"? If so, isn't this redundant with item 2 (but IMO more clearly stated)? * Item 4 (first list): What is an "empty line"? Is whitespace allowed? What about exclamation points? What about comments? * Item 6 (first list): What does "prefixed" mean? * Are '!', '$', '\\', '$$$', '<*' and '*>' recognized as special tokens only if they are surrounded by whitespace? (All of these characters except for backslash are considered extended alphabetic characters in standard scheme.) * Later in the design rationale, it is mentioned in passing that '!' is only recognized as indentation at the beginning of a line. Does that mean before any whitespace? If so, that fact should be mentioned in the specification (which currently suggests that '!' could mixed freely with spaces or tabs). * Item 1 (second list): What are lines with "initial indent"? What happens if a line is not consistently indented? What is meant by "preceding line"? Does that mean "preceding non-empty line"? (if so, what does "empty line" mean?) * Item 3 (second list): What does "completely ignored" mean? How does this relate to the "preceding line" of item 1 (second list)? * Is '!' considered whitespace? * Item 5 (second list): What does it mean for an expression to "start indented"? * Item 6 (second list): Do datum comments ignore intervening '!' characters as well? * In the rules that say neoteric expression are read (not sweet expressions), how are '!', '$', '\\' and '$$$' handled? * Item 7 (second list): What does it mean exactly that block comments are "removed"? * Item 1 (third list): Regarding GROUP, what does it mean "it represents no symbol at all, located at that indentation"? * Item 2 (third list): What does "restart list processing" mean? What is "the right-hand-side"? What are "its sub-blocks"? What happens if there's more than one '$' on a line? * Item 3 (third list): Does "indentation" mean "non-empty indentation"? (and does that definition apply generally?) In the "entire sweet-expression that follows" what is considered the indentation of the first line of that expression? * Item 4 (third list): What are "un-indented sweet expressions"? * Why is there a distinction made between "advanced sweet-expression features" and the rest of the spec? * In the paragraph immediately following the third list: * "MUST only be accepted ... is active" => "MUST NOT be accepted ... is not active" * When are sweet expressions accepted but "indentation processing" is not active? (in collecting lists?) * What does it mean that a "character sequence" begins with "exactly the marker's first character"? In "{$}", why is the '$' not considered a "character sequence"? * IMO, it should probably be specified whether "#!no-sweet" disables curly-infix. * In the examples, why are the s-expressions not indented according to the nearly-universally accepted conventions? * The use of '$', '$$$', '<*', and '*>' as special tokens should be mentioned in the "Backwards compatibility" section. These are all considered extended alphabetic characters by standard scheme. * If an implementation implements sweet expressions by default, then they will have to be careful about writing symbols that contain '$', '<*' or '*>'. * In the design rationale, there's a section entitled "Blank lines". Are these the same as the "empty lines" referenced in the specification? If so, I suggest using just one term, and defining it clearly in the spec. * 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. Regards, Mark