On 28 October 2010 10:15, Alexander Kjeldaas <[email protected]> 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. _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
