On Tue, Jul 15, 2014 at 9:23 AM, J. Ian Johnson <i...@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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
