struct-copy doesn't recognize contracted super struct info

[sorawee]

#lang racket

(module first racket
  (provide (contract-out (struct foo ([x any/c])))
           (contract-out (struct (bar foo) ([x any/c]))))
  (struct foo (x))
  (struct bar foo ()))

(require 'first)

(struct-copy bar (bar 1) [x #:parent foo 2])

fails with:

struct-copy: identifier not bound to a parent struct
  at: foo
  in: (struct-copy bar (bar 1) (x #:parent foo 2))

Note that this has been failing, even before #2700.

[sorawee]

The problem is that https://github.com/racket/racket/blob/master/racket/collects/racket/private/define-struct.rkt#L1002 uses free-identifier=? to test if the specified parent id is the same as one of identifiers in the struct info or not. Because contract-out generates a new identifier, they won't be free-identifier=? to each other.

One possible fix is to add yet another struct prop, say, struct-identity-info to keep the original identifier around. contract-out will attach this property, which contains the original identifier. This would allow struct-copy to use the content of struct-identity-info if it's available. Note that struct infos generated by define-struct won't need this property.

Does this look like a good idea?

CC: @mflatt, @rmculpepper

[rfindler]

Can contract-out arrange to make the parent of bar be the foo it is exporting? Robby

…

On Thu, Jul 2, 2020 at 8:13 AM sorawee ***@***.***> wrote: The problem is that https://github.com/racket/racket/blob/master/racket/collects/racket/private/define-struct.rkt#L1002 uses free-identifier=? to test if the specified parent id is the same as the identifier in the struct info or not. Because contract-out generates a new identifier, they won't be free-identifier=? to each other. One possible fix is to add yet another struct prop, say, struct-identity-info to keep the original identifier around. contract-out will attach this property, which will allow struct-copy to use the content of struct-identity-info if it's available. Note that struct infos generated by define-struct won't need this property. Does this look like a good idea? CC: @mflatt <https://github.com/mflatt>, @rmculpepper <https://github.com/rmculpepper> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3270 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADBNMGD7TQRXBSS3CQNJFDRZSBW7ANCNFSM4OKNQK7Q> .

[sorawee]

Not really. In fact, a better example is:

#lang racket

(module first racket
  (provide (contract-out (struct foo ([x any/c])))
           (struct-out bar))
  (struct foo (x))
  (struct bar foo ()))

(require 'first)

(struct-copy bar (bar 1) [x #:parent foo 2])

In the above program bar is not contract-out-ed at all. So there's really nothing that we can do with the struct info of bar.

[rfindler]

Maybe in that example, bar isn't really a substruct of foo (outside of the module)?

[rfindler]

@chrdimo what do you think about these examples?

[samth]

Saying that bar isn't a substruct of foo is effectively saying that we can't use struct-copy on bar at all, right? Note that this does work, suggesting that contract-out thinks that bar is a substruct of foo:

#lang racket
(module first racket
  (provide (contract-out (struct foo ([x any/c])))
           (struct-out bar))
  (struct foo (x))
  (struct bar foo ()))

(module second racket
  (require (submod ".." first))
  (provide (contract-out (struct (bar foo) ([x any/c])))))
(require 'second)
(bar 1)

[sorawee]

@samth the super struct position was recently deprecated (by me), precisely because I don't have a good way to check that foo is a super struct of bar after it's contracted.

[sorawee]

Maybe in that example, bar isn't really a substruct of foo (outside of the module)?

Doesn't that imply that the following code should fail?

#lang racket

(module first racket
  (provide (contract-out (struct foo ([x any/c])))
           (struct-out bar))
  (struct foo (x))
  (struct bar foo ()))

(require 'first)

(foo-x (bar 1)) ; 1

But clearly, you have put a lot of effort into making it work (impersonator, chaperone, etc.).

[rfindler]

That's a good point.

I do think that (struct-out bar) should behave the same as (contract-out (struct bar ....)) where the ellipsis contains the right number of any/cs just in the same way that (provide x) should be the same as (provide (contract-out [x any/c])). Unfortunately, the latter is not always the same for some technical reasons and so we might not get the former either. Perhaps this is one of those situations where we wish we coudl fix it, but we won't end up fixing it.

Which brings us back to the earlier example, where both bar and foo are in contract-out but not quite cooperating enough(?).