[racket] struct-copy with sub-types

I've added some examples to help clarify. How do these look?

(struct fish (color weight))
(define marlin (fish 'orange-and-white 11))
(define dory (struct-copy fish marlin
                          [color 'blue]))
dory

(struct shark fish (weeks-since-eating-fish))
(define bruce (shark 'grey 110 3))
(define chum (copy-struct shark
                          [weight #:parent fish 90]
                          [weeks-since-eating-fish 0]))
chum

(code:comment "subtypes can be copied as if they were supertypes,")
(code:comment "but the result is an instance of the supertype")
(define not-really-chum
  (copy-struct fish bruce
               [weight 90]))
not-really-chum


On Fri, Mar 25, 2011 at 10:17 AM, Nadeem Abdul Hamid <nadeem at acm.org> wrote:
> Ok, yes, on second thought, I guess it is fine. With your fix,
>
> (struct-copy sub (sub 1 2 3) [c 4])   ==> (sub 1 2 4)
> (struct-copy sub (sub 1 2 3) [b 4])   ==> (sub 1 4 3)
> (struct-copy base (sub 1 2 3) [b 4]) ===> (base 1 4)
>
> is that right? So that sentence applies to the third situation.
>
> I guess when the second one didn't work, I assumed somehow that "id"
> could only be the struct type where the field was actually defined. So
> it was a bug. Sorry for the confusion,
>
> --- nadeem
>
>
> On Fri, Mar 25, 2011 at 11:08 AM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> The phrase "immediate instance of id" is meant to suggest that it
>> doesn't have the extended fields.
>>
>> What would you have written?
>>
>> Robby
>>
>> On Fri, Mar 25, 2011 at 10:04 AM, Nadeem Abdul Hamid <nadeem at acm.org> wrote:
>>> 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
>>>>>
>>>>
>>>
>>
>