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.
[Oops: I wrote this message several days ago but my ssh connection
died and I forgot to send it afterwards, and so there's a little bit
of outdated material here. Oh well.]
On Fri, 19 Mar 2004, Andre van Tonder wrote:
> On Thu, 18 Mar 2004 campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
>
> > - 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.
But what's the point of writing a SRFI if it can be _pure_ library
functionality? Even certain SRFIs such as SRFI 34, exception handling,
may be implementable in pure R5RS, but they still make sense as SRFIs
because they're intended to become part of the internals of the system.
On the other hand, if SYNTAX-COMPUTATIONS (...) is _pure_ library
functionality that is intended to make _no_ changes to _any_ part of
the implementation, what's the point?
> > - 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.
Er, why do you need my permission?
(By the way, while I _have_ decided to have SRFI 46 use CYOE, I haven't
yet decided exactly how to use it: should it be
(syntax-rules [<ellipsis-token>] (<literal> ...) <clause> ...)
or
(syntax-rules (<literal> ...) [<ellipsis-token>] <clause> ...)
or
(syntax-rules (<literal> ...)
([<ellipsis-token>] <pattern> <template>)
...)
et cetera?)
> > - 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.
Thanks.
> > - 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 expect the reason you're avoiding those mentions is that you're
assuming the underlying SYNTAX-RULES implementation deals with them,
but I think this is a dangerous assumption that could potentially cause
_very_ unportable code.
> > - 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.
Need it really be so? Could there not be a *SYNTAX-DO used internally
and a SYNTAX-DO atop it that performs pattern matching?
> > - 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).
This sounds unnecessarily complicated and you lose the linearness of
SYNTAX-DO, which is one of the reasons for using it in the first place.
> > - 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.
This discussion should probably fork off, away from a general comments
& questions thread.
> > - 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.
I'm not sure what you mean here. Could you rephrase that answer?
> > - 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...).
How about SYNTAX-COMPUTE, SYNTAX-LET*, or SYNTAX-SEQUENCE? (They're
all vague, except for LET*, but they're all less vague than '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.
Apologies: I misread the specification of SYNTAX-EQ?. Still, I don't
like EQ?: I think EQV? would be a much better choice.
Actually, here's what I'd really like for the set of comparators:
(SYNTAX-FREE-IDENTIFIER=? <id1> <id2>)
Compare ID1 & ID2, which most buth be identifiers. Two identifiers
are considered free-equal (?) if they both refer to the same top-
level or lexical binding.
(define-syntax syntax-free-identifier=?
(syntax-computations ()
((free-identifier=? ?id1 ?id2)
(let-syntax
((check
(syntax-computations (?id2)
((check ?id2) #t)
((check ?id3) #f))))
(check ?id1)))))
(SYNTAX-BOUND-IDENTIFIER=? <id1> <id2>)
Compare ID1 & ID2, which must both be identifiers. Two identifiers
are considered bound-equal (?) if one would capture references to
the other.
(define-syntax syntax-bound-identifier=?
(syntax-computations ()
((bound-identifier=? ?id1 ?id2)
(let-syntax ((?id1 (syntax-computations () ((?id1) #t))))
(let-syntax ((?id2 (syntax-computations () ((?id2) #f))))
(?id1))))))
(SYNTAX-LITERAL-IDENTIFIER=? <id1> <id2>)
Compare the names of ID1 & ID2, discarding any other attributes.
This cannot be expressed as a simple SYNTAX-COMPUTATIONS macro.
[Is this a good idea?]
(SYNTAX-EQV? <atom1> <atom2> [<symbol=?>])
Compare ATOM1 & ATOM2 for simple datum equality; if they are both
symbols, use SYMBOL=? to compare them; if SYMBOL=? is not passed,
check for either free or bound equality.
[If it is determined that SYNTAX-LITERAL-IDENTIFIER=? is a good
idea, might it be better to have that be SYMBOL=?'s default?]
(SYNTAX-EQUAL? <stx1> <stx2> [<symbol=?>])
Compare STX1 & STX2 for structural equality, comparing symbols with
SYMBOL=?, which defaults to SYNTAX-FREE-IDENTIFIER=? disjoined with
SYNTAX-BOUND-IDENTIFIER=?.
[Again, should we use SYNTAX-LITERAL-IDENTIFIER=? for SYMBOL=?'s
default?]
> > - 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,
It will? I've seen LET/CC used only in PLT. Historically, CATCH is
the name for the special form that captures a continuation.
> 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...
They aren't, but superfluous abbreviation causes cancer of the, er,
brev, perhaps? I just don't like unnecessary abbreviations.
> Thank you again
> Andre