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