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

[Sebastian Sylvan]

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, 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 think both of those look crowded -- smashing operator punctuation up
> against symbols basically never looks good to me. The right amount of
> spacing isn't generally available without proper typesetting, but a
> full space is a lot closer than no space at all.
>
> Why not "myPoint # x" and "myPoint . x"?
>

Well, again this is just preference, but to me I'd like selectors to
not have space between the record and the label, they still need to be
"connected", but with a symbol which is small enought to help you
easily see what's what.

> >
> > 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 symbol actually does look better, but isn't on any English
> keyboards to the best of my knowledge. I can get it in my setup with
> <compose-key> o x, but not many people have a compose key assigned.
> Also, this may just be a bug, but currently, ghc gives a lexical error
> if I try to use that symbol anywhere, probably just since it's not an
> ASCII character.

Hmm. On my keyboard it's Shift+4. Strange that it's not available on
other keyboards. As far as I know that symbol means nothing
particularly "swedish". In fact, I have no idea what it means at all
=)

> > 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.
>
> I disagree, there are plenty of cases where it's just what you want,
> and saves you from introducing a lambda term for nothing. This occurs
> very often in parameters to higher order functions. A simple example
> would be something like "filter (not . null)", or "any ((`elem`
> consumers) . schVertex)". More sophisticated examples come up all the
> time, and often the functions being composed have some parameters
> applied to them. I disagree that it's just for obfuscation.

Well, what I said was that for any more complex cases than that it
ends up being hard to read. In a lot of examples when peopl abuse
function compostion you really have to think for quite a while before
you can figure out what it does, whereas if they had just written out
everything in a few more steps it would've been immediatly clear.

"filter (not # null)" isn't in any way worse than "filter (not .
null)" IMO. Also, like I said earlier, I would even prefer a larger
operator for compositon since in that case you want spaces around the
operator (at least that's how I always use it in maths) and the dot is
perhaps a bit too small in that case (easy to miss it on a glance,
misstaking it for application).
How about (<>) for the ring operator? That's almost a circle. "filter
(not <> null)" looks pretty nice IMO.
At any rate, I think that the dot is such a good symbol that I'd
prefer to give it to a primitive operator (such as module or record
selection) rather than something which is user-defined (but in the
prelude). Plus, if the record system was halfway decent, I'm pretty
sure record selection would occur a few orders of magnitude more often
than function composition. So from a pure "popularity" standpoint
record selection would win (assuming it's agreed that three uses for
the dot operator is too much and one needs to go, that is).

/S

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