Re: Initial comments & questions Andre van Tonder 25 Mar 2004 21:15 UTC
On Tue, 23 Mar 2004 xxxxxx@autodrip.bloodandcoffee.net 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.