[racket] struct-copy with sub-types

In that case, the documentation should probably be updated clearly to
note this different behavior -- the last sentence of the current:
http://docs.racket-lang.org/reference/struct-copy.html
says:

"
(struct-copy id struct-expr [field-id expr] ...)
....
The result of struct-expr can be an instance of a sub-type of id, but
the resulting copy is an immediate instance of id (not the sub-type).
"

Which is why I didn't interpret the behavior as a bug, but a
limitation (albeit weird) of struct-copy.

--- nadeem


On Fri, Mar 25, 2011 at 10:49 AM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> Hi, and sorry for the delay. I've pushed a fix for this, altho it is
> more like a new feature since the code below still doesn't work--- you
> have to explicitly name the struct that had the field when it isn't
> the first argument to struct-copy.
>
> Robby
>
> On Fri, Mar 25, 2011 at 7:52 AM, Pierpaolo Bernardi <olopierpa at gmail.com> wrote:
>> On Wed, Mar 23, 2011 at 00:49, Nadeem Abdul Hamid <nadeem at acm.org> wrote:
>>> Is there anything like struct-copy that works to functionally update a
>>> field value in a structure, where the field happens to be defined in
>>> the super-type? In the example below, I want to "functionally update"
>>> a field of the sub structure inherited from the base definition...
>>>
>>>
>>> (struct base (a b) #:transparent)
>>> (struct sub base (c) #:transparent)
>>>
>>> (define S (sub 1 2 3))
>>>
>>> (struct-copy sub S [c 4]) ; works
>>> ; doesn't work: (struct-copy sub S [b 4])
>>> (struct-copy base S [b 4]) ; produces a base, not sub
>>
>> No answers?
>>
>> it looks to me that
>>
>> (struct-copy sub S [b 4])
>>
>> should work, but it doesn't.  Isn't this a bug?
>>
>> If it is not considered a bug, maybe the docs need a clarification?
>>
>> Cheers
>> P.
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/users
>>
>