Records in Haskell

Matthew Farkas-Dyck strake888 at gmail.com
Tue Jan 3 05:28:27 CET 2012


On 02/01/2012, Simon Peyton-Jones <simonpj at microsoft.com> wrote:
> It seems to me that there's only one essential missing language feature,
> which is appropriately-kinded type-level strings (and, ideally, the ability
> to reflect these strings back down to the value level). Given that, template
> haskell, and the HList bag of tricks, I'm confident that  a fair number of
> elegant records packages can be crafted. Based on that experience, we can
> then decide what syntactic sugar would be useful to elide the TH layer
> altogether.
>
> I think we can do this part without much trouble, once the dust has settled
> on -XPolyKinds.  It certainly fits with all the work we've been doing
> recently on the kind system. I agree that it's a fairly basic requirement;
> for example, it's also assumed by
> http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
>
> Specifically
>
> *        Allow String as a new kind
>
>
> *        Now you can define classes or types with kinds like
>
> MyCls :: String -> a -> Constraint
>
> T :: String -> *
>
>
> *        Provide type-level string literals, so that "foo" :: String
>
> Open questions:
>
> *        Is String (at the kind level) a synonym for [Char]?  I'm inclined
> *not* to do this initially, because it would require us to have promoted
> character literals too -- and the implementation of record labels as strings
> of type-level cons-cells is not going to be efficient.
>
> *        If String is not a kind level synonym for [Char], maybe it should
> have a different name.  For example,   "foo" :: Label?  Or Atom?   After
> all, if it doesn't behave like a Haskell string it probably should not have
> the same name.

I agree. In this case, though, I think we ought to allow
kind-polymorphic quoted type-level literals, thus:
"foobar" :: Label
or
"foobar" :: String
at least.

> *        Are there any operations over Labels?
>
> *        I don't know exactly what you have in mean by "the ability to
> reflect the type-level string at the value level".
>
> Simon
>
> From: Gershom Bazerman [mailto:gershomb at gmail.com]
> Sent: 31 December 2011 19:12
> To: Simon Peyton-Jones
> Cc: Greg Weber; glasgow-haskell-users at haskell.org
> Subject: Re: Records in Haskell
>
> On Dec 31, 2011, at 1:28 PM, Simon Peyton-Jones wrote:
> The trouble is that I just don't have the bandwidth (or, if I'm honest, the
> motivation) to drive this through to a conclusion. And if no one else does
> either, perhaps it isn't *that* important to anyone.  That said, it clearly
> is *somewhat* important to a lot of people, so doing nothing isn't very
> satisfactory either.
>
> Usually I feel I know how to move forward, but here I don't.
>
> Simon
> It seems to me that there's only one essential missing language feature,
> which is appropriately-kinded type-level strings (and, ideally, the ability
> to reflect these strings back down to the value level). Given that, template
> haskell, and the HList bag of tricks, I'm confident that  a fair number of
> elegant records packages can be crafted. Based on that experience, we can
> then decide what syntactic sugar would be useful to elide the TH layer
> altogether.
>
> Beyond that, it would really help namespacing in general to appropriately
> extend the module system to allow multiple modules to be declared within a
> single file -- or, better yet, "submodules". I know that this introduces a
> few corner cases that need to be thought through -- what happens with
> overlapping declarations, for example. But I tend to think the path here is
> relatively straightforward and obvious, and the added expressive power
> should make namespacing issues much more tractable. Like the type-level
> strings proposal, this isn't about implementing records as such -- rather,
> it's about generally extending the expressive power of the language so that
> record systems--among other things--are easier to write.
>
> Cheers,
> Gershom
>



More information about the Glasgow-haskell-users mailing list