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.