Records in Haskell
anthony_clayden at clear.net.nz
Fri Mar 2 01:38:46 CET 2012
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
> > > 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
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.
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
(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?)
More information about the Glasgow-haskell-users