[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