[Haskell] Extensible records: Static duck typing

Sebastian Sylvan sebastian.sylvan at gmail.com
Wed Feb 6 07:16:44 EST 2008


On Feb 6, 2008 11:33 AM, Simon Peyton-Jones <simonpj at microsoft.com> wrote:

>
>
> This sort of disagreement means that nothing gets done. After my
> experience with the wiki page, I don't believe anything will get done
> until one of the core ghc developers makes some arbitrary decisions
> and implements whatever they want to, which will then eventually
> become part of the standard by default.
>
>
>
>
> This is the sort of situation where a "benign dictator" is needed. I have
> no strong feelings about which of all of these (all very good) proposals get
> implemented, but I do have a strong opinion that the lack of "proper"
> records is hurting Haskell quite a bit.
>
>
>
> Any of them will do, just get it in there! I'm assuming that Simon {PJ,M}
> et al. won't make an obviously terrible choice, and GHC seems to be the de
> facto standard anyway, so if they just implemented something in GHC that
> would be good enough for me, and a shoe-in for a future standard.
>
>
>
> Since you are taking my name in vain, I had better respond!  I wish I felt
> as confident of my good taste as you do. My last attempt to implement
> records (with Umut Acar, more or less the design in the "proposal for
> records" paper) involved rather significant changes to the type checker, and
> I was reluctant to commit to them without stronger evidence that it was a
> good design.
>
>
>
> I'm not so despondent about the Wiki page. It's already a good start.
> Don't give up too soon!
>
>
>
> You say that "lack of proper records is hurting Haskell".   I think it'd
> help to give much more structure to that statement.  "proper records" means
> different things to different people.   After all Haskell already has
> somethng you can call "records" but they obviously aren't "proper" for you.
>
>
>

So to clarify that statement. Honestly the number one problem I have with
the current records system is that labels share the same namespace. This
makes interfacing with any C library using structs quite painful. This is
why I say that I don't really care which gets implemented. The current
system is *painful* IMO, so anything which improves on it would be welcome
(even if just puts the record accessors in a per-record namespace, where
with syntactic sugar to avoid having to qualify it).

Now, I do think that if we're going to remedy that situation, we might as
well take the opportunity to make them lightweight (i.e. not require a data
type), with polymorphic fields etc, but those all of those things are
distant second priority to the one "showstopper" for the current records,
IMO.
Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell/attachments/20080206/58630c51/attachment.htm


More information about the Haskell mailing list