Re: PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011
Evan Laforge writes: > That's a good point, but even if not totally logical I think the > automatic "Rec -> X" function is more important than the X meaning. [...] > It might be nice to do the same with update functions, but those > aren't even generated automatically (anyone got a generics thing that > cranks those out?). See my other post for a way of doing both of these. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011
Anthony Clayden
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.fairba...@cl.cam.ac.uk
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011
> (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). That's a good point, but even if not totally logical I think the automatic "Rec -> X" function is more important than the X meaning. Functions are more resistant to change (for instance, I changed from String to Data.Text but could keep the old recString as a function when the field named changed), so while I think the sugar to bring names into scope is handy, I think functional access should be encouraged as the "main" way to do it. The whole tension between syntactic convenience of pattern matching and the flexibility of function accessors in the face of change is kind of unfortunate. It mirrors the OO dilemma of x.y vs. x.y(), which some OO languages do away with altogether. So I'd want to go the other way by making functional access and update more convenient and prominent rather than syntactical. Maybe we could have a little extension of view patterns where "f (field ->) = y" is transformed to "f (field -> field) = y". It's still a shadow, but at least now it works with any function. It might be nice to do the same with update functions, but those aren't even generated automatically (anyone got a generics thing that cranks those out?). ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011
>Isaac Dupree writes:
> On 02/24/10 13:40, Martijn van Steenbergen wrote:
> > Ian Lynagh wrote:
> >> I have a feeling I'm in the minority, but I find record punning an ugly
> >> feature.
> >>
> >> Given
> >> data T = C { f :: Int }
> >> we implicitly get
> >> f :: T -> Int
> >> which punning shadows with
> >> f :: Int
> >> whereas I generally avoid shadowing completely.
> >
> > I agree with Ian.
>
> I tend to agree.
>
>
>
> -Isaac
>
(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).
I wonder: if a programmer from Mars landed into Haskell a la
GHC 2010 (that is, unburdened by history back to v1.3),
wouldn't it be the scare-quotes 'implicit' field selector
that seems the odd man out?
After all, the program text declares { f :: Int }, and in
all uses of the field label apart from selecting, it _is_ an Int.
Where does this function thing come from?
By the way, it seems you can arrive at the same
level of confusion like this (declared in a distinct scope):
> f (C { f }) = f-- f :: T -> Int
- Anthony
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
