[Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)

Sebastian Sylvan sebastian.sylvan at gmail.com
Thu Nov 17 15:02:09 EST 2005


On 11/17/05, Cale Gibbard <cgibbard at gmail.com> wrote:
> On 17/11/05, Sebastian Sylvan <sebastian.sylvan at gmail.com> wrote:
> > On 11/17/05, Greg Woodhouse <gregory.woodhouse at sbcglobal.net> wrote:
> > > Isn't there a potential for confusion with function composition (f . g)?
> > >
> > > That being said, I like this idea (I just need to think it through a bit).
> > >
> >
> > I've been wanting this for ages. It's SO much better than the current
> > horribly broken records we have.
> > There could be confusion with function composition, but there's no
> > ambiguity (compositon have spaces around the dot, while record
> > accessors do not).
> > Personally I think that the dot is way to good of a symbol to be
> > "wasted" on function composition. I mean, how often do you really use
> > function composition in a way which doesn't obfuscate your code? I use
> > ($) way more often than (.). Some people do use it more often than I
> > do, but I find that in most cases except simple "pipelined" functions
> > it only makes the code harder to read.
> > I'd rather function composition was left out of the prelude
> > alltogether (or defined as (#) or something).
> >
> > Anyway. The current records system is a wart.
> >
>
> Actually, I didn't mention this in the other post, but why not the
> other way around? Make record selection (#) or (!) (though the latter
> gets in the way of array access), and leave (.) for function
> composition. Personally, I'd like something which looked like an arrow
> for record selection, but most of the good 2-character ones are
> unavailable. (~>) is a bit hard to type and looks wrong in some fonts.
> There's a "triangle" which is not taken, and isn't so hard to type
> (|>).
>
> I never really understood the attachment to (.) for record selection.
> There's no reason that we have to make things look like Java and C.

This is going to be highly fuzzy and completely subjective. Here it goes.

I find that for selections (records, or qualified modules etc.) I want
the operator to be small and so that the important "word groups"
become the module or the record.
When I read the following two variants
myPoint#x
myPoint.x

I definatly prefer the latter. In the first one the operator is so
large that it makes "myPoint" and "x" blend together as you read it
(step away from the monitor and squint and you'll see what I mean),
whereas in the second example the operator is small and makes the two
operands naturally separate slightly when reading it, which makes it
easier to tell which identifier is accessed. Also, it's certainly not
a BAD thing if Haskell uses the same operators as other languages.

With function composition, though, the operator is just as important
to identify when reading as the operands are. So I don't think a "big"
operator is a problem there - likewise I have no problems with ($)
being "large".

How about (¤)? It looks like a ring to me, I'm not sure where that's
located on a EN keyboard, but it's not terribly inconvenient on my SE
keyboard. f ¤ g looks better than "f . g" for function composition, if
you ask me.


That's my subjective view on why the dot-operator is so darn nice, anyway.

Oh and to answer to your other post. I realise that function
composition is a fundamental operation, but it's so fundamental that
it's quite useless for most real-world cases unless your willing to
seriously ubfuscate your code.
IMO it really only works well for simple "chains" like "foo . bar .
oof . rab" but as soon as you start working with functions that take
more parameters it starts looking very unreadable and you'd be better
off to just use $ or write out paranthesis and apply arguments
explicitly, or better yet, introduce some temporary descriptive
variables in a let or where clause.

It's a matter of personal preference, but I certainly haven't found it
used enough to warrant giving it perhaps the best symbol on the
keyboard.


/S
--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862


More information about the Haskell-Cafe mailing list