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" <sa...@cs.indiana.edu> To: "J. Ian Johnson" <i...@ccs.neu.edu> Cc: "dev" <dev@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 <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
