PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011

Jon Fairbairn jon.fairbairn at cl.cam.ac.uk
Sat Feb 27 05:52:53 EST 2010


Anthony Clayden
<anthony_clayden at clear.net.nz>
writes:
> (I know how you're always looking for things to take out of
> Haskell ...)
>
> I can see the ugliness of having a name with two
> incompatible types (especially in the same scope).

Granted.

> After all, the program text declares { f :: Int }, and in
> all uses of the field label apart from selecting, it _is_ an Int.

It's not; it's shorthand for something else (a bare f in a
programme doesn't get you an Int -- which one would it be?). One
of the nice things about Haskell is that if you know the name of
something and the something has a type, then you know something
about all the possible values it can have. In current Haskell, f
here isn't a name in that sense, which is a big pity (you can't
pass a field label as an argument to a function, for example).

> Where does this function thing come from?

It comes (as you imply) from it's use as a field selector. I'd
say that (and field update) were its primary uses. It would be
far better to make field labels proper first-class entities that
have a translation into lambda calculus (or System F as you
will).

I would much rather see field labels having their own type,
so that

  data F t = F {f:: H t}

declares the type F, the constructor F and a name 

f:: Selector (F t) (H t)

the language definition needn't make whatever is inside Selector
directly visible to the programmer, but we can think of it as
secretly being a pair of functions

 ((F t -> H t), (H t -> F t -> F t))

Now f x would be an overloaded meaning of application¹. And
r{f=g} would be shorthand for (magic-snd f g r), where magic-snd
is just snd made suitable for application to Selector. (Frankly,
I'd rather lose the r{f=g} syntax and provide an operator that
accesses the second part of f so that it can be applied as a
function, eg (f←g) r. This (f←g) would then also be a first
class function.)


Doing it this way would get rid of the peculiar multiple type
issue, make it completely clear what field labels translate to
and give us field labels as proper first class entities.


[1] as it currently is, and I'm not suggesting allowing general
overloading of application, but at least this way we'd know what
f was

-- 
Jón Fairbairn                                 Jon.Fairbairn at cl.cam.ac.uk




More information about the Haskell-prime mailing list