[racket] Structs and syntax-local-value ... how is the struct name overloaded?

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 <scott at 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.eastlund at 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 <scott at 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 scott at 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 scott at pointyhat.ca
> 200-1575 W. Georgia
> Vancouver, BC V6G2V3
>
> _______________________________________
> To iterate is human; to recur, divine
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140119/6cae3939/attachment.html>