[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: syntax-local-value patch for discussion

From: Stefan Israelsson Tampe
Subject: Re: syntax-local-value patch for discussion
Date: Fri, 9 Dec 2011 12:49:33 +0100


On Thu, Dec 8, 2011 at 10:58 PM, Ian Price <address@hidden> wrote:
Stefan Israelsson Tampe <address@hidden> writes:

> So I tried to get hold of the macro binding. So with the following patch wich should be enogh
> for me to make progress porting rackets syntax parse to guile.
> Would be very glad if we could find a interface to expose this information that is sane
> and rigid manner. So we should discuss this feature.
As it stands, I agree it is pretty simplistic, but I'm not sure what to
propose :) What is the intended use cases for this? A compile-time
values mechanism?

In syntax-parse they associate atribute data to an attribute variable that also is a macro.
So later on when the symbol is used the compiler want to get hold of the attribute data.
So there is a need to get hold on the lambda that is associated with the symbol and then lookup
the data via a weak hash table.
> Anyway about the patch.
> I added a fluid that is setted with a closure that captures enough syntax information
> so that we can lookup the macro value local or global. It basically uses the same method
> as psyntax macroexpander.
The patch looks fine to me, although I admit I have little experience
with psyntax.

> Now we can write,
> (define-syntax info
>   (lambda (x)
>     (syntax-case x ()
>       ((_ x)
>         (pk (syntax-binding-info (syntax->datum #'x)))
>         #'#f))))
FWIW, I wouldn't expect to have to pass a raw datum to any procedure
with a syntax prefix. If we keep this procedure, I think the
syntax->datum should be hid, or the procedure renamed.

An idea is to  change the name to symbol-local-data. Another idea is to return
the lookup function directly (I think that this might be needed as well to make sure
that the same symbol has the same interpretation in two contexts)
So for this function we could use the name  local-symbol-lookup-function
and then builed any secondary interfaces on that inside a proper module.
> So with this I can attach meta information to macros local or not by
> using a weak hash.
I have 'define-type' & 'type-case' macros, basically copied from
racket's plai language[0][1] , that suffers from a complete lack of
error handling in the case where the type-id is not, in fact, a
type-id. If I were to use this mechanism, I would create a weak hash of
datatype-ids, adding them to the hash with 'define-type', and checking
if they are in the hash in my 'type-case' macro. Would that be right?

Yes you can use this mechanism to do what you wan't. There might be better ways though.
1. In a separate module make the type-id:s and let them be macros with the lambda put as a key
in a weak key hash table
2. in using the type-id in the expansion of a type-case you can now lookup the symbol's context and deduce the  macro binding, get the lambda and check if it is in the weak key hash table. and as you say be able to do the sanity check.

Another method would be to have the type-id:s syntactic context is a module toplevel variable,
and from the syntax object deduce if it is a toplevel variable and if so check if the id is in the hash table.
Maybe there is tools alredy made that does this in a simple straightforward way?

If you would define a type-id locally then the only way to later check for valid type-id is to do
(let-syntax ((type-id (register-and-return (lambda (x) (error "this is a type-id not a syntactic element")))
     the-code-that-uses-type-id ...)
where you would use my suggestion.

the machanism I propose
1. I can post these if people want them
Ian Price

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Cool, these libraries can be useful,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]