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