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.
On Tue, 23 Mar 2004 campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
> > > ... 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.
Perhaps one could state something like:
For portability, this SRFI implements forms
define-syntax*
let-syntax*
letrec-syntax*
to be used in conjuction with the transformer keyword
syntax-computations.
Implementors are encouraged, where allowed, for example, by a module
system, to fold this usage of define-syntax*, ... into the regular
syntactic binding forms define-syntax, ...
> > > - 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.
Could you expand on this?
> > > - 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?
Well, one could do something like
(syntax-bind ((<pat> <comp>))
<body>)
= (syntax-bind* ((x <comp>))
(let-syntax* ((deconstruct
(syntax-computations ()
((deconstruct <pat>) <body>))))
(deconstruct x)))
In fact, I had this in an earlier version. The problem was that with this
definition the pattern variables in <pat> would not shadow correctly. The
solution would be to change syntax-apply, which is already very complex
and slow.
> 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>)
>
> (SYNTAX-BOUND-IDENTIFIER=? <id1> <id2>)
Thank you for the implementations. Yes, I'll include something like this.
> (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?]
Not sure.
> (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?]
I would be inclined to simply choose one default (no third argument).
If the programmer wants something more complicated, they can easily
write that themselves.
> (SYNTAX-EQUAL? <stx1> <stx2> [<symbol=?>])
> Compare STX1 & STX2 for structural equality, comparing symbols with
I would leave this out. It is unlikely to be used much.
> It will? I've seen LET/CC used only in PLT. Historically, CATCH is
> the name for the special form that captures a continuation.
I'm thinking of scrapping the continuation manipulations, since they are
perhaps somewhat too closely bound to the current continuation-style
impementation.