On 28 October 2010 10:15, Alexander Kjeldaas
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.