Gábor Lehel <illissius <at> gmail.com> writes:
>> On Mon, Feb 20, 2012 at 4:41 AM, AntC <anthony_clayden <at> clear.net.nz>
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