[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Initial comments & questions

This page is part of the web mail archives of SRFI 53 from before July 7th, 2015. The new archives for SRFI 53 contain all messages, not just those from before July 7th, 2015.

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

  - 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)))
             (for-each (lambda (irr)
                         (display "  ")
                         (write irr)
                        (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)
              (display "Syntax debug: ")
              (display message)
              (for-each (lambda (irr)
                          (display "  ")
                          (write irr))
              `(,(rename 'syntax-bind) ,stx-k ())))))

Some naming quibbles:

  - 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 &
  - Why abbreviate 'continuation' everywhere?  If you want brevity,
    how about SYNTAX-CATCH & SYNTAX-THROW instead of the much longer
    (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.