Gábor Lehel
2012/2/25 Gábor Lehel
: Please correct me if I've misunderstood or mischaracterized any aspect of
DORF.
Okay, I did end up misunderstanding and mischaracterizing at least two aspects of DORF.
Re-reading the wiki page:
http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFie...
Sorry, Gábor, but you've still mis-understood. I tried so hard to explain it clearly!
it's clear that you would not have to write fieldLabel declarations for every single field of every single record,
But yes you do have to declare every fieldLabel that's going to appear in a record decl within a module compiled under DORF. (Even if the field only appears once in one record -- sorry!) You can, though, mix records/fields from modules compiled under H98 monomorphs (providing no clash of names!)
only for the ones you wish to be shared and usable polymorphically. By default, fields of individual records would be specific to that record (monomorphic in the type of the record),
No! the record decl would (try to) generate an instance for every field of every record, then the compile would fail because there was no fieldLabel declared.
So the difference between DORF and my variant would be: ...
(You've misunderstood DORF, so got the next bit wrong.)
It wasn't clear to me before that DORF retains record-monomorphic fields, ...
(It doesn't!)
In DORF you can presumably still use a record-monomorphic field selector to help infer the concrete type of the record
Kind-of: you can declare a fieldLabel with a monomorphic type (if you want it to only appear in a single record), then it helps type inference.
... One troubling consequence of DORF -- again, if I'm understanding things correctly -- is that due to implicit field instances a module import can change the meaning of your program:
No you aren't understanding correctly, so: no, a module import can't change the meaning. (It might mean the program fails to compile, due to name clash.) I've responded to same later posts to clarify this. AntC