Hi,
On Thu, Dec 8, 2011 at 10:58 PM, Ian Price <ianpric...@googlemail.com>wrote:
> Stefan Israelsson Tampe <stefan.ita...@gmail.com> 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.
>
Ok,
> >
> > 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.
Anyway
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
> 0. http://docs.racket-lang.org/plai/plai-scheme.html
> 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,
/Stefan
