Initial comments & questions

[campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx]

First, thanks for designing a comprehensive interface to this -- you
beat me to it before I completed syntax-lib... --.

Second, I've got a lot of comments and questions.  These are just my
initial thoughts on the SRFI.  I'll likely have many more later, but I
thought these were plenty for now...

Some of them are directly related to SRFI 46 -- which, mumble, I ought
to finish up at some point --, or have come up on the SRFI 46 mailing
list:

  - Having a new top-level definition form, DEFINE-SYNTAX-COMPUTATION,
    is cumbersome and shouldn't be necessary; DEFINE-SYNTAX should be
    universal for introducing syntax transformers, and the same should
    go for LET-SYNTAX and LETREC-SYNTAX.  Yes, it's true, you can't
    implement COMPUTATION-RULES to be a valid transformer keyword like
    SYNTAX-RULES in straight R5RS, but I think that small price to pay
    is OK, because, after all, this is a request for implementors to
    implement what you propose here.
  - You're going to hit the _exact_ same ellipsis problems that are
    fixed by SRFI 46.  (My plans for SRFI 46 are to use CYOE, by the
    way.)  Why not specify CYOE from the start?
  - Does COMPUTATION-RULES support tail patterns?

Issues regarding the document:

  - Could you move the reference implementation into a separate file?
    It's a bit of a bother to have it within the document text; it's 
    pretty big.
  - More examples, please!  For instance, a LETREC implementation that
    is much cleaner than R5RS's, or Oleg's example of a record definer
    that 'generates identifiers' (cf. that thread somewhere on c.l.s).
  - Very little is mentioned about hygiene, which I'm worried about.
  - Very little is mentioned about shadowing.
  - I'd like some comments on the topic of efficiency of the system.

Technical issues unrelated to SRFI 46:

  - Is SYNTAX-INVOKE/C really necessary?  Couldn't the continuations be
    regular syntax computations that just ignore their continuation?
  - Is pattern matching available in SYNTAX-DO's bindings?
  - Are there provisions for multiple return values?  (This would be
    unnecessary with 'yes' to the previous question.)
  - If the answer to those last two questions is 'no,' then why?
  - Couldn't SYNTAX-ERROR be a _lot_ simpler? --
      (define-syntax syntax-error (syntax-rules ()))
  - I fear that the syntactic list-processing routines may turn into
    a complete reinvention of SRFI 1.  This is a much bigger issue
    that I haven't thought much about yet.  More on this later...
  - Are there any operations on syntactic vectors?
  - I'm not entirely sure if it's a good idea, but I have a nagging
    suspicion that macro writers may want a utility for generating
    debugging messages.  It of course can't be implemented in terms of
    plain SYNTAX-RULES, but it can trivially be defined with other
    macro systems, e.g.:
      (define-syntax syntax-debug-message
        (lambda (stx)
          (syntax-case stx ()
            ((syntax-debug-message ?k ?message ?irritant ...)
             (display "Syntax debug: ")
             (display (syntax-object->datum (syntax ?message)))
             (newline)
             (for-each (lambda (irr)
                         (display "  ")
                         (write irr)
                         (newline))
                       (syntax-object->datum
                        (syntax (?irritant ...))))
             (syntax (syntax-bind ?k ()))))))
      (define-syntax syntax-debug-message
        (transformer ; Explicit renaming
          (lambda (form rename compare)
            (destructure ; Scheme48 extension -- whatever
                (((#f stx-k message . irritants)
                  form))
              (display "Syntax debug: ")
              (display message)
              (for-each (lambda (irr)
                          (display "  ")
                          (write irr))
                        irritants)
              `(,(rename 'syntax-bind) ,stx-k ())))))

Some naming quibbles:

  - COMPUTATION-RULES -- I'd prefer SYNTAX-COMPUTATIONS or something.
  - SYNTAX-DO -- I don't like this at all.  It's not very descriptive
    and it clashes with the DO syntax in regular Scheme.  While it may
    be a good point that it does nothing more than 'do' a computation,
    and this is also what Haskell uses, it still isn't descriptive to
    just say 'do,' and it still has the clash.
  - I _loathe_ the <- bit of SYNTAX-DO.  It's there seemingly _only_
    for consistency with Haskell; it serves no useful purpose other
    than to bother people like me, and that purpose isn't very useful,
    so it doesn't count.
  - SYNTAX-EQ? -- why that and not SYNTAX-EQUAL? ?  The name EQ? has
    connotations of that of the Scheme procedure EQ?, which compares
    for identity, so I'd avoid it for structural comparison.
  - SYNTAX-FOLDL & SYNTAX-FOLDR: SRFIs 1, 13, and 43 all use FOLD &
    FOLD-RIGHT; SRFI 44 uses FOLD-LEFT & FOLD-RIGHT.  Given these
    traditions, I'd prefer FOLD & FOLD-RIGHT, or at worst FOLD-LEFT &
    FOLD-RIGHT.
  - Why abbreviate 'continuation' everywhere?  If you want brevity,
    how about SYNTAX-CATCH & SYNTAX-THROW instead of the much longer
    SYNTAX-LET-CURRENT-CONTINUATION and SYNTAX-INVOKE-CONTINUATION?
    (And SYNTAX-INVOKE/C may not even be necessary, either.)
  - I don't like the name SYNTAX-LET/CC.  It implies that it's letting
    the current continuation _be_ something, when in fact it's
    _capturing_ the current continuation.