Overloaded record fields
anthony_clayden at clear.net.nz
Thu Jun 27 01:10:08 CEST 2013
> Mateusz Kowalczyk <fuuzetsu <at> fuuzetsu.co.uk> writes:
> On 24/06/13 11:04, Roman Cheplyaka wrote:
> > * Mateusz Kowalczyk <fuuzetsu <at> fuuzetsu.co.uk> [2013-06-24
> > 10:47:09+0100]
> >> Restricting function composition to have spaces around it will
> >> require changing a large amount of existing code if one is
> >> willing to use it.
> Sure that it's unreasonable to have them change some of their code to
> use new, cool features. I'm just questioning whether it's absolutely
> necessary to do it by forcing restrictions on what is probably the
> most commonly used operator in the whole language.
For my 2-penn'orth, requiring spaces around composition won't break any of
my code: I always do put spaces.
Re use of 'infix' dots, I grew up on Russell & Whitehead's Principia
Mathematica, Wittgenstein's Tractatus, BCPL (dots inside names), LISP's
dotted pairs (which IIRC always have surrounding spaces), SQL's
I find it is Haskell that is 'odd man out'.
OTOH, there is a high cost in breaking that existing code with non-spaced
composition, and I'm not convinced that record-field access alone is a
sufficient benefit. (This is what SPJ would call a low power to weight
What's more, the new dot syntax seems a bit weird:
A dotted right-section is allowed, so presumably the wiki example could go:
getPersonId e = e.PersonId
getPersonId = (.PersonId) -- eta reduce(?)
What do these terms mean/are they valid?
(.PersonId) e -- prefix application
e (.PersonId) -- postfix application??
let f = (.PersonId) in e.f -- no Has instance for f
let fullName r = r.firstName ++ " " ++ r.lastName
e.fullName -- trying to use Virtual field
So I'm thinking that this dot operator is not really an operator, neither
is it part of the name as in module prefixes(?)
(I'll add some more thoughts to SPJ's comment.)
More information about the Glasgow-haskell-users