[racket] Struct fields in struct-info + match enhancements

On Wed, May 14, 2014 at 12:35 PM, J. Ian Johnson <ianj at ccs.neu.edu> wrote:
> tl;dr if you use struct-info in your programs, I might break them. Please continue reading.
>
> I had a PR a while ago suggesting a change to struct-copy due to its unhygienic nature with fields. It did not go through since there wasn't enough information in the struct-info to separate the struct-name and the field-name. Because struct-info does not have a procedural-only interface, changing it to instead or also hold the individual field identifiers would be backwards incompatible. However, I also expect that struct-info manipulation outside of core Racket is rare.
>
> Is there anyone out there that would be affected by a this change that would be unwilling to make slight modifications to support the new struct-info?
> I ask not because of struct-copy itself, but for an additional enhancement to racket/match: named field selection from structs instead of positional only.
> I'm getting bitten by pervasive refactoring woes whenever I add fields to structs. All of my match patterns must change to have an extra _ somewhere.

I don't understand why this would require a backwards-incompatible
change to struct-info.

Also, this discussion is confusing because it's not clear whether you
mean the dynamic value produced by the `struct-info` procedure, or the
structure type transformer binding. I think you mean the latter, in
which case I expect you could do what you want by implementing
`prop:struct-info` appropriately with an extended structure, and
handling existing values (such as six-element lists) appropriately
with defaults.

Sam