Gábor Lehel
On Mon, Feb 20, 2012 at 4:41 AM, AntC
wrote:
Folks, I've put my 'Record in Haskell' proposal on the wiki http://hackage.haskell.org/trac/ghc/wiki/Records as suggestion 5 Declared Overloaded Record Fields.
Feedback welcome.
I was wondering whether it wouldn't make sense to have some syntax within the record itself, instead of at the top level, to declare, "I'm definitely declaring a new record field", versus "I'm definitely re-using an existing record field", versus "If this record field already exists I'm re-using it, otherwise I'm declaring it". ...
We're trying to minimise the changes (and be backward compatible, if possible), so I think a single compiler option at module level is enough, without introducing tricky syntax in the record decls. Option absent means H98 behaviour. Option present means _all_ my record decls are using pre-defined record fields. Note that this only affects the modules where the records (and fieldLabels) are declared. In the application code which uses the records, just apply the field selector function to the record, or use familiar record update syntax. You don't have to know how the record or fields were declared. (That is, you can import H98 style records and DORF style records quite happily.) That suggests the best way to organise the database definitions/decls is: - base module: data dictionary (fieldLabels only) - record/structures module(s) grouped by application areas: records only plus interface to your data store; plus validation and manip utilities - application modules: business code possibly plus ad-hoc records (may be decl'd H98 style) Well stap me if that way of organising isn't best practice anyway!
Regarding the polymorphic update / higher-rank fields issues, I'm not competent to address them in earnest, but: isn't this primarily an ImpredicativeTypes issue? If GHC had full support for ImpredicativeTypes (whatever that means), would it work?
~g
Thanks Gábor, neither am I really competent, which is why I asked SPJ to look at an early prototype. Since he says it's an unscalable hack, I'll stop there. At least my proposal uses Has/get/set (with its type-level sugar) and supports type-changing update. So (I reckon) it's equal to or ahead of any other proposal -- except for those which need whole-scale syntax re-engineering and breaking a whole heap of code. AntC