On Thu, 18 Mar 2004 xxxxxx@autodrip.bloodandcoffee.net wrote:

Thank you for your helpful comments!

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

I couldn't agree with you more.  However, unfortunately, as you noted:

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

I would say the advantage of the current specification is that it can be
essentially a library on top of syntax-rules, requiring no extra support
from implementors nor anything beyond R5RS.

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

Yes, I have hit this problem.  I have found the somewhat standard
(... ...) solution not to be good enough in cases where ellipses appear
in the syntactic continuation and where the continuation can be rewritten
an arbitrary number of times during the computation, since each rewrite
loses a level of ellipses-quotation.  I suspect that CYOE might resolve
this problem, which would be another strong argument in favor of it.  I
will look into it and if I can get it to work, with your permission I'll
include it.

>   - Does COMPUTATION-RULES support tail patterns?

If the underlying SYNTAX-RULES supports them, which is a question I'll
leave to the implementors of the latter.

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

Okay - I'll include some more examples in the next draft.

>   - Very little is mentioned about hygiene, which I'm worried about.
>   - Very little is mentioned about shadowing.

I'll see if I can come up with something intelligent to say about this.

>   - I'd like some comments on the topic of efficiency of the system.

My experience: On MzScheme very slow.  Much faster on Petite Chez.  I do
suspect, however, that a much faster implementation can be written on
systems supporting syntax-case, implementing syntax-do in terms of
with-syntax as I allude to in the text.  It might be fun to try.

>   - Is SYNTAX-INVOKE/C really necessary?  Couldn't the continuations be
>     regular syntax computations that just ignore their continuation?

You're probably right.  Thank you for pointing that out.  I'll try it.

>   - Is pattern matching available in SYNTAX-DO's bindings?

No.  I thought about it but it would probably significantly complicate
syntax-apply to correctly handle them.

>   - Are there provisions for multiple return values?  (This would be
>     unnecessary with 'yes' to the previous question.)

No.  But you can return an s-expression and deconstruct it with
syntax-match as I did for example in the match-record example:

             (syntax-match (name)
               ((make-name labels) ..etc..))

to extract the constructor and field labels returned by the
computation (name).

>   - Couldn't SYNTAX-ERROR be a _lot_ simpler? --
>       (define-syntax syntax-error (syntax-rules ()))

I'll try it.

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

I was afraid of this.  I am seriously considering making only the core
forms (and one or two of the derived forms) part of the SRFI, demoting
all the rest to the status of examples, thus avoiding SRFI mission
creep...

>   - Are there any operations on syntactic vectors?

See previous answer.

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

This would be useful, but can perhaps be left to the discretion of
implementors.

>   - COMPUTATION-RULES -- I'd prefer SYNTAX-COMPUTATIONS or something.

Yes.  I also prefer your suggestion.  I'll change it.

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

Understood.  I haven't been able to come up with a better name, though.
The advantage of the current syntax is that anyone familiar with
Haskell-like imperative programming, based on the monadic do and return
primitives used in much of the literature, will know immediately how to
use them correctly.  (Actually, I have a gripe with the regular Scheme DO,
which is not very descriptive, which I never use, and which clashes with
my own nefarious purposes for DO...).

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

I concede that this is not very Schemely.  Probably syntax-do, as a
binding construct, should follow the model of LET* (even if it may be a
little less readable).  I'll modify that.

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

It is not structural comparison.  In any case, Oleg Kiselyov has drawn my
attention to the fact that there is more than one type of equality of
symbols, so I'll reorganise this bit of the interface.

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

Okay, I'll change them.  As I said above, though, I might demote these to
mere examples.

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

Yes, but let/cc will be familiar to many in the Scheme community, and
in this case fits more easily with the rest of the interface than
call/cc.  Also, I'm not sure abbreviations are necessarily a bad thing,
but I know opinions diverge on this...

Thank you again
Andre