I've done some experiments with my fixed-up "sugar", which implements I-expressions. I-expressions are a key part of sweet-expressions too, so I'm keen on making sure that they have the best and clearest possible definition.
Here are some of the results of "sugar" that make sense to me; I'll show the I-expression, => what-it-maps to, and ;commentary. In short, the spec and code differ on many points - in some cases I think the I-expression spec is correct (compared to "what I'd expect") but the code isn't, sometimes the code is correct but the spec is not (compared to "what I'd expect"), and sometimes neither is correct. =============================== ' x y => (quote (x y)) ; okay, a ' followed by whitespace quotes the entire expression to follow, inc. child lines. ; That's sensible, and useful, though it's not entirely clear from the spec. ; Presumably the spec really means expr -> QUOTE hspace+ expr ; where it says: expr -> QUOTE expr ; but this is NOT clear from the spec - I'd call that a spec bug. But the code gets this right. 'x y => ((quote x) y) ; I think this code behavior is reasonable, but it needs to be clearly documented somewhere. ; This _ESPECIALLY_ makes me think that the spec intended ; expr -> QUOTE hspace+ expr. If there's no whitespace after ', the expression ; right after it is gobbled up and the larger indentation, etc., isn't taken into account.... ; which would map to s-expr. Okay, so we've extracted a reasonable spec interpretation... ; until I try the next test: ' ' x y => (quote ((quote) x y)) ; BUG? I think this is a bug in the code. I would think that a ' followed by any expression ; should be fine, even if it's another ' - if we fix/interpret the spec as above, then ; clearly ANY expression should be allowed after the ' ... even another '. ; Thus, I think this should be: ; (quote (quote (x y)) ; That's certainly how I read the spec, too. Anyone else agree, or disagree? x y => (x y) ; This is just basic indentation processing - no problem. Spec and code and ; "what I'd expect" all agree. group x y => ((x y)) ; This makes sense. "group" essentially adds (...) around its subexpression. Fine! group x => (x) ; This makes sense too; I think the code passes the "what is reasonable" test here. ; But this seems to point out a spec bug; in the spec, the productions: ; expr -> GROUP head ; expr -> head ; have EXACTLY the same effect - which would in theory mean that GROUP has ; no effect if there's only a head. But the code doesn't do that, and I think it's because ; the spec is wrong and the code is right (in this case). ; Frankly, I think that GROUP ought to be a single, simple rule that recurses to expr. group x y => (x y) ; BUG? Isn't this an error? This is the same result as without "group", but ; I would think this should be ((x y)) instead. ; In general, I think "group" should just mean "add extra (...) around stuff". For the moment, I'm completely avoiding abbreviation-whitespace, and after "group" always press return and indent. This at least lets me test out the rest. But before "real use", these issues need to be fully spec'ed, and 100% correctly implemented. NOBODY is going to use a notation for programming unless they're VERY confident that their code will be correctly interpreted. --- David A. Wheeler
