struct-copy fails if the structure type transformer binding is renamed

[lexi-lambda]

The following example fails with a syntax error:

#lang racket/base

(module struct racket/base
  (provide (struct-out point))
  (struct point (x y) #:transparent))

(require (rename-in 'struct [point point2d]))

(struct-copy point2d (point2d 1 2) [x 3])

struct-copy: accessor name not associated with the given structure type
  in: point2d-x

This happens because struct-copy synthesizes accessor names by concatenating the symbol provided as the structure type with each field symbol, separated by a hyphen. This seems incorrect, given that it assigns significance to the identifier’s name when really its binding should be all that matters.

[LeifAndersen]

heh, lol, who needs hygeen anyway... ^_^

[AlexKnauth]

Oh, wow

[LeifAndersen]

I think this can actually be solved by passing in a local-expand to the id used in struct. I'll give this a shot.

[LeifAndersen]

Oh wait, wrong way....never mind. :/

[AlexKnauth]

No, this should be solved by using the struct-info to get the correct accessors. (I thought that's what it already did; apparently not (no, it does, but what is doesn't do is use the struct-info to get the correct struct name))

[lexi-lambda]

It’s not possible to fix struct-copy to get the correct accessors (I would have done it myself if it were possible) because it specifically does not require the user to specify the whole struct field names. That is, it allows users to specify x instead of point-x or point2d-x in the original example. A naïve implementation could try to make guesses based on matching name suffixes, but it isn’t too hard to come up with pathological cases in the presence of struct subtyping.

The right fix for this is probably changing something much more fundamental about information exposed by struct, which is a lot trickier to do in a backwards-compatible way.

[AlexKnauth]

It would need to go through all the accessors, searching for one which has that field at the end? That's not ideal. Does the struct info have actual field names in it anywhere, separate from the accessors?

[lexi-lambda]

No, it does not. There’s not even an obvious way to add it, given that it’s possible to have duplicate field names in the presence of struct inheritance. This is totally legal:

(struct foo (a))
(struct bar foo (a))

The struct-copy macro gets around this with the #:parent option, but that’s a little bit hacky.

Personally, I think the best fix for this would be to introduce a way to do struct copying at a low level rather than having it be a derived concept, which would avoid the slicing problem that struct-copy has. Improving the static type information provided by struct would be helpful, too, but it wouldn’t solve all of the issues with struct-copy and subtyping.

[samth]

What @lexi-lambda said. struct-copy is hopeless and can't be fixed without major changes to how structs work.

[sorawee]

#:parent can also go wrong...

#lang racket

(module a racket
  (provide a)
  (struct a (b-c) #:transparent))

(require 'a)
(struct a-b a (c) #:transparent)

(struct-copy a-b (a-b 1 2) [b-c #:parent a 10])
(struct-copy a-b (a-b 1 2) [c 10])

Both outputs (a-b 1 10)