[Haskell-cafe] Current thinking on CompositionAsDot issue in
chrisdone at googlemail.com
Thu Oct 28 04:34:05 EDT 2010
On 28 October 2010 10:15, Alexander Kjeldaas
<alexander.kjeldaas at gmail.com> wrote:
> I think I recognize this issue from common lisp. Basically the code becomes
> verbose because accessor functions usually need to redundantly encode the
> name of the module or struct in its name. The alternative is to require
> users to import qualified, and that doesn't deal with the occasional
> intra-module collision.
> This is a typical large-software-system issue and it annoys me a little that
> Haskell seems to have inherited the problems from common lisp.
> I worry that in large systems, a very conservative coding standard is needed
> with quite verbose naming conventions as that's the only safe way to avoid
> these conflicts in a large system while allowing refactoring code etc.
As someone with a nontrivial project (5k~ LoC) I recently I
experienced first hand this issue. I first went with records with
whatever field names I wanted, and then imported qualified. But then I
need a module for every single record type in case (and they did) of
clashes. I have 40~ record types in this project, so that's just no
feasible. I did it anyway. I really don't like having to qualify
everything though. I end up with a huge import list of as X, as Y, as
Z, etc. and this is difficult to follow. And I don't like reading
qualified code so much. If I import with more descriptive names, e.g.
`as Submission', `as SubmissionAuthor', etc. it becomes more verbose
than merely prefixing the accessor functions. I tried out record
systems like Has, because that system has accessors which only care if
a record /has/ a certain field, and new ones can be constructed
arbitrarily. But then I miss out of Haddock's documentation, not to
mention deriving goodies and pattern matching. So I stuck with the
Common Lisp approach.
More information about the Haskell-Cafe