[racket-dev] Semantics of struct-out with except-out

Code will break if it uses struct to produce structs, provides a renamed an accessor function, and uses an unhygienic feature to name the field.
The features I know of are struct-copy, struct* match patterns, and contract-out's struct form.

No one but me probably did this, and that's what led to my discovery of the unhygienic state of struct-copy and my previous regex-based PR to "fix" it.
I don't /need/ to rename fields, since in the case that a field accessor is renamed to something entirely different (e.g., Foo-x => Qux), a renamed field doesn't quite benefit readability of a struct-copy that uses field "x". If renaming Foo-x to Foo-y, then a x -> y rename is helpful. I have not yet come across a need for this however.
I can wait on this feature of struct-out (and probably contract-out's struct form as well).

Thanks,
-Ian
----- Original Message -----
From: "Sam Tobin-Hochstadt" <samth at cs.indiana.edu>
To: "J. Ian Johnson" <ianj at ccs.neu.edu>
Cc: "dev" <dev at racket-lang.org>
Sent: Tuesday, July 15, 2014 9:35:01 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Semantics of struct-out with except-out

On Tue, Jul 15, 2014 at 9:23 AM, J. Ian Johnson <ianj at ccs.neu.edu> wrote:
> I'm working on enhancing struct-info to carry field names as symbols to do nice hygienic things:
>
> http://lists.racket-lang.org/users/archive/2014-July/063271.html
>
> I now see that struct-out always provides all field accessors in the static struct-info associated with the struct identifier.
> This means the following produces (list 0 1) instead of an error saying that Foo-x is undefined, or something along those lines:
>
> #lang racket/load
> (module A racket
>   (struct Foo (x y))
>   (provide (except-out (struct-out Foo)
>                        Foo-x)))
> (module B racket
>   (require 'A)
>   (match (Foo 0 1)
>     [(Foo x y) (list x y)]))
> (require 'B)
>
> To make struct-out not so greedy about what it provides would require a backwards-incompatible change. The problem then is, should we (I) do it?

No, the current behavior is reasonable -- static struct info provides
access to the accessors.

> Part of me says yes for "intuitive semantics" and part of me says no because the implications are that struct-info values will have to be meticulously checked and rebound to mangled identifiers with new information when passing through provide-specs that can affect struct identifiers.
> Should that burden be pushed to future provide-spec implementors? Should it already have been?
> The alternative is to provide special syntax in struct-out to do all the "common" provide-spec stuff and still not play nice with other provide-specs.
> The upside to this is no name mangling, but the downside is yet more special syntax for what provide-specs should already do, IMHO.
>
> I'm planning to extend struct-out to allow renaming the fields associated with a struct so the following (contrived example) is possible:

I think this should be delayed to a separate change. Are there cases
in the code base currently where this would be used?

Sam