[plt-scheme] Describe Function

Those ones don't work on everything (fixnums, for example, altho that
may be the only thing) and probably the guarantees of the behavior of
those is less. And, of course, they are unsafe. :)

Robby

On Tue, Nov 10, 2009 at 5:57 PM, Doug Williams
<m.douglas.williams at gmail.com> wrote:
> Oh, there is an unsafe-vector-set! - and unsafe-struct-ref and set!.
>
> On Tue, Nov 10, 2009 at 4:51 PM, Doug Williams
> <m.douglas.williams at gmail.com> wrote:
>>
>> Instead of the 'everything is a struct' view, you could also use an
>> 'everything is a vector view' and with unsafe-vector-ref take things apart -
>> even when they are opaque.
>>
>> (require scheme/unsafe/ops)
>>
>> (define-struct s (a b c))
>>
>> (define s1 (make-s 1 3 5))
>>
>> s1 -> #<s>
>> (unsafe-vector-ref s1 0) -> #<struct-type:s>
>> (unsafe-vector-ref s1 1) -> 1
>> (unsafe-vector-ref s1 2) -> 3
>> (unsafe-vector-ref s1 3) -> 5
>>
>> I assume that as long as I stay within the bounds of the underlying
>> representation (and probably sometimes even if I don't - negative indices
>> are allowed), unsafe-vector-ref will give gladly me the pieces. At least
>> there is no unsafe-vector-set!
>>
>> Doug
>>
>> On Tue, Nov 10, 2009 at 11:29 AM, Doug Williams
>> <m.douglas.williams at gmail.com> wrote:
>>>
>>> Sounds good. I was just thinking that a lower level implementation could
>>> avoid the need to create a vector just to get the variant. But for my code
>>> it's no big deal.
>>>
>>> On Tue, Nov 10, 2009 at 11:21 AM, Robby Findler
>>> <robby at eecs.northwestern.edu> wrote:
>>>>
>>>> On Tue, Nov 10, 2009 at 12:18 PM, Doug Williams
>>>> <m.douglas.williams at gmail.com> wrote:
>>>> > Robby,
>>>> >
>>>> > I am going to add your variant procedure to the describe collection.
>>>>
>>>> Great!
>>>>
>>>> > Are you
>>>> > happy with the name 'variant' and the contract (-> any/c symbol?)?
>>>>
>>>> Yes. (You may want to use substring isntead of regexp-match.)
>>>>
>>>> > What is
>>>> > the relationship between this and object-name?
>>>>
>>>> Nothing really. object-name is per-object (and not everything has a
>>>> name).
>>>>
>>>> >  It seems that for actual
>>>> > structs they return the same value. Would it make sense to change
>>>> > object-name to return the same value as variant in those cases where
>>>> > it
>>>> > (i.e., object-name) returns #f? This would trivially make this
>>>> > functionality
>>>> > available in #lang scheme, which seems to be a good thing.
>>>>
>>>> I don't think that that change is really a good idea at this point.
>>>> Probably would break lots of stuff.
>>>>
>>>> Robby
>>>>
>>>> > Doug
>>>> >
>>>> > On Tue, Nov 10, 2009 at 7:43 AM, Robby Findler
>>>> > <robby at eecs.northwestern.edu>
>>>> > wrote:
>>>> >>
>>>> >> On Tue, Nov 10, 2009 at 8:41 AM, Dave Herman <dherman at ccs.neu.edu>
>>>> >> wrote:
>>>> >> >> This probably doesn't help Doug, but here is another way to define
>>>> >> >> the
>>>> >> >> function linked above:
>>>> >> >
>>>> >> > That's neat, thanks! Has struct->vector always worked on
>>>> >> > non-structs?
>>>> >>
>>>> >> I'm not sure about always, but at some point a while ago, Matthew
>>>> >> decided that all values are structs (in the sense that you could have
>>>> >> implemented everything with structs and scope, etc even if some of
>>>> >> them are implemented in C) and adapted the primitives to make them
>>>> >> behave accordingly.
>>>> >>
>>>> >> Robby
>>>> >
>>>> >
>>>
>>
>
>