Overloaded record fields

[AntC]

> 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 
table.field.

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 
ratio.)

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.)

AntC