Records in Haskell

[AntC]

Ian Lynagh <igloo <at> earth.li> writes:

> 
> On Thu, Mar 01, 2012 at 11:32:27PM +0000, AntC wrote:
> > AntC <anthony_clayden <at> clear.net.nz> writes:
> > 
> > > 
> > > Ian Lynagh <igloo <at> earth.li> writes:
> > > 
> > > > 
> > > > But I think you are agreeing that (leaving aside the issue of whether
> > > > the design is reasonable) the above variant would indeed allow the user
> > > > to choose the behaviour of either SORF or DORF.
> > > > 
> > > 
> > > No, not the "user to choose", but the implementor. We can't possibly try 
to 
> > > support both approaches.
> > > 
> > 
> > Sorry, I mis-interpreted your last paragraph. I think you meant:
> > 
> > ... allow the user to choose [public or restricted namespacing] behaviour 
> > under either the SORF or DORF proposal.
> 
> Yes, exactly.
> 
> > Yes-ish (leaving aside that issue). Under SORF you hve an extra behaviour:
> > - use String Kinds and your label is public-everywhere and
> >    completely uncontrollable.
> > - (So someone who imports your label can't stop it getting re-exported.)
> > - This is unlike any other user-defined name in Haskell.
> > 
> > I'm not sure whether to call that extra behaviour a 'feature' (I tend more 
> > to 'wart'), but it's certainly another bit of conceptual overload.
> 
> Right, but other people would prefer the SORF behaviour to the DORF
> behaviour.
> 

Would they? How could we know? Most of the posts here have been from people 
who don't get anywhere near to understanding the issues. There's been a 
voicifereous poster who wants to have lots of fields with the same name and 
have them each "mean" something different. (No, I don't understand either.)

Under DORF they could get the public-everywhere behaviour by exporting and 
importing unqualified (just like H98!).

> But note that if this was implemented, then the only difference between
> the 3 is in the desugaring. So if you desugar r.f only then you get
> SORF, r.F only then you get DORF (well, with different syntax,
> probably), and if you desugar both then you get the choice.
> 
> Thanks
> Ian
> 

Sorry Ian, but I've got conceptual overload. I feel I understand DORF 
behaviour not just because I designed it, but also because I can (and have!) 
prototyped it under GHC v7.2, including public-everywhere and controlled 
import/export -- see my additional attachment to the implementor's page.

With Kinds and Stringy Kinds and type-to-Kind equality constraints I feel I 
want to better understand how that affects the design space. I don't think 
that's possible yet, even in v7.4(?)

Right from the beginning of SPJ's SORF proposal, I've had a feeling that ghc 
central, having introduced the new whizzy Kinds, now wants to find a use for 
them. Surely there would be other applications for Kinds that would be clearer 
use cases than patching-up Haskell's kludgy record design?

We're focussing too narrowly on this representation-hiding issue. There are 
other important differences between SORF and DORF (which I've tried to explain 
on my comparison page on the wiki). Nothing you've said so far is being 
persuasive.

(BTW on the comparison wiki, I've put some speculations around using Kinds 
behind the scenes as an implementation for DORF -- implementor's choice. 
Because it's behind the scenes we could use a more compact/specific variety of 
Kind than String. But it's still in danger of suffering the uncontrollable 
public-everywhere issue. Could you suggest an improvement?)

AntC