[Haskell-cafe] Some thoughts on Type-Directed Name Resolution

[AntC]

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