Records in Haskell

[Evan Laforge]

> It ''also'' demonstrated, to me, that qualified imports are horrible
> when used on a large scale. It happened all the time, that'd I'd
> import, say, 10 different data types all qualified.  Typing map
> (Foo.id . BarMu.thisField) and foo Bar.Zot{x=1,y=2} becomes tedious
> and distracting, especially having to add every type module when I
> want to use a type. And when records use other types in other modules,
> you have ''a lot'' of redundancy. With the prefixing paradigm I'd write
> fooId and barMuThisField, which is about as tedious but there is at
> least less . confusion and no need to make a load of modules and
> import lines. Perhaps local modules would solve half of this
> problem. Still have to write “Bar.mu bar” rather than “mu bar”, but
> it'd be an improvement.

I disagree about qualified imports, in my experience they're even more
useful as the scale increases, because there are many more modules
each symbol could come from, and many more name conflicts, and of
course there starts to be module name conflicts.  I don't find it much
of an imposition because I have an automatic tool to add and remove
imports when needed, and once the import is already there keyword
completion works on it.  Grepping for '^data .. =', I have 199 types,
of which 97 are probably records, spread over 296 modules.  The 97
records are spread over 50 modules, but in practice there are a number
with 5-10 and then a long tail with just 1 or 2 each.

However I entirely agree a better syntax for records would make
programming clearer, more concise, and more fun.  I also agree that
one module per record is annoying, so I wind up with many records per
module, so I have record prefixes anyway.  Access is annoying, but not
so bad, I think.  It's true '(ModuleB.recField2 . ModuleA.recField1)
val' is inferior to val.field1.field2, but at least the functions
compose and if you make a habit of reducing the dots by defining a few
precomposed functions you can cut out a lot of the work of moving a
field, or more likely, grouping several fields into a nested record.
But the really annoying thing is that modification doesn't compose.
Record updates also don't mix well with other update functions.  So,
just to put give another data point, here's an extreme case:

set_track_width view_id tracknum width = do
    views <- gets views
    view <- maybe (throw "...") return $ Map.lookup view views
    track_views <- modify_at "set_track_width"
        (Block.view_tracks view) tracknum $ \tview ->
            tview { Block.track_view_width = width }
    let view' = view { Block.view_tracks = track_views }
    modify $ \st ->
        st { state_views = Map.insert view_id view' (state_views st) }

I inlined the 'modify_view' function, so this looks even nastier than
the real code, but it would be nice to not have to define those helper
functions!  In an imperative language, this would look something like

    state.views[view_id].tracks[tracknum].width = width

Of course, there's also monadic vs. non-monadic getting its claws in
there (and the lack of stack traces, note the explicit passing of the
function name).  So if I hypothesize a .x syntax that is a
modification function, some handwavy two arg forward composition, and
remove the monadic part (could get it back in with some fancy
combinator footwork), theoretically haskell could get pretty close to
the imperative version:

    let Map.modify k m f = Data.Map.adjust f k m
    (.views .> Map.modify view_id .> .tracks .> modify_at tracknum .>
.width) state width
    -- or, let set = (...) in state `set` width

It's also nice if the field names can be in their own namespace, since
it's common to say 'x.y = y'.  I'm not saying I think the above would
be a good record syntax, just that I think composing with other modify
functions is important.  Passing to State.modify is another obvious
thing to want to do.

The above is an extreme case, but I've lost count of the number of
times I've typed 'modify $ \st -> st { field = f (field st) }'.  I
don't even have to think about it anymore.

I know that these are the problems that lenses / first class labels
libraries aim to solve, so if we're talking only about non-extensible
records, I'm curious about what a language extension could provide
that a library can't.  Simply not being standard and built-in is a big
one, but presumably the platform is an answer to that.

It would be nice if record updates and access to come with no
performance penalty over the existing system, since updating records
forms a large part of the runtime of some programs, I'm not sure if
the libraries can provide that?