If syntax-local-value is returning something other than the value you put in, that's a bug. It shouldn't be wrapping it or changing it in any way. Do you have a program where you bind something via define-syntax that satisfies struct-info?, and get something out via syntax-local-value that doesn't?
Carl Eastlund On Sun, Jan 19, 2014 at 11:27 PM, Scott Klarenbach <sc...@pointyhat.ca>wrote: > But I don't see how the same binding can be a transformer and also return > something else (like a list, or a checked-struct-info-thing) via > syntax-local-value. > > If I bind my-fn as a transformer, then any other macros that use it with > syntax-local-value will receive the transformer procedure back, not any > special meta data. And if I bind it as meta data directly, ie > (define-syntax my-fn 'something) then it works with syntax-local-value but > any attempts to use it as a transformer result in illegal syntax. > > Even if I create a transformer that returns a struct which implements both > prop:procedure and prop:struct-info, using that binding with > syntax-local-value will return the transformer procedure itself, rather > than the final struct. > > > > On Sun, Jan 19, 2014 at 8:04 PM, Carl Eastlund <carl.eastl...@gmail.com>wrote: > >> Yes, I believe that the name of a structure defined by "struct" is bound >> at syntax-time to a value that implements both prop:procedure, so that it >> can expand to a use of the constructor when used in an expression, and >> prop:struct-info so that it can be use to look up static information when >> passed to relevant macros. >> >> Carl Eastlund >> >> >> On Sun, Jan 19, 2014 at 11:00 PM, Scott Klarenbach <sc...@pointyhat.ca>wrote: >> >>> How is it that the definition of (struct my-name (x y)) can bind >>> *my-name* both as a #<procedure:my-name> at runtime and a >>> transformer-binding *my-name* that at compile time (via >>> syntax-local-value) produces #<procedure:self-ctor-checked-struct-info>.? >>> >>> Or, put another way, how can I define a transformer *my-fn* that >>> produces syntax, but that also exposes hidden meta-data under the same >>> binding to other macros that might wish to know about the binding at >>> compile time? >>> >>> I'm specifically wondering how the overloading works. Is it some clever >>> use of prop:procedure? >>> >>> Thanks. >>> >>> -- >>> Talk to you soon, >>> >>> Scott Klarenbach >>> >>> PointyHat Software Corp. >>> www.pointyhat.ca >>> p 604-568-4280 >>> e sc...@pointyhat.ca >>> 200-1575 W. Georgia >>> Vancouver, BC V6G2V3 >>> >>> _______________________________________ >>> To iterate is human; to recur, divine >>> >>> ____________________ >>> Racket Users list: >>> http://lists.racket-lang.org/users >>> >>> >> > > > -- > Talk to you soon, > > Scott Klarenbach > > PointyHat Software Corp. > www.pointyhat.ca > p 604-568-4280 > e sc...@pointyhat.ca > 200-1575 W. Georgia > Vancouver, BC V6G2V3 > > _______________________________________ > To iterate is human; to recur, divine >
____________________ Racket Users list: http://lists.racket-lang.org/users
