[Haskell-cafe] Re: Design your modules for qualified import
Andrew Coppin wrote: Until very recently, it was not at all clear to me that there is actually a very simple solution to this problem: import Text.ParserCombinators.Parsec as P Now I only have to write P.runPaser, which is much shorter. This fact probably needs to be mentioned more loudly - I'm sure I'm not the only person to have overlooked it... I have one efficient way to find all the needed language features without reading the specification from the start to the end or waiting till my questions get answered. The point is that common sense will indicate you where the required features should be logically located in the language grammar. E.g. if you want something related to imported modules it is logical to check all the alternatives available in import declaration. Then I check the grammar how the production for import declaration (impdelc) looks like (where it can be used etc.). Mostly it is enough sometimes I need to check the language specification since it is not obvious from the grammar. The result is that when I learn a new language the first thing I'm looking for is the formal grammar. Luckily most languages have it available. Some languages (like Haskell) are obsessed with shortcuts and the result is that their grammar is a bit cryptic; others (like VHDL) have it just great - production names clearly indicate what they actually do. On the other side haskell has nice online report :-) Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Design your modules for qualified import
On Fri, 6 Jun 2008, Achim Schneider wrote: Jan-Willem Maessen [EMAIL PROTECTED] wrote: There's one caveat: Always choose descriptive names, even if you are assuming that you will usually use a qualified import. The following are wonderful names, even though they conflict with the prelude: null filter map lookup import Prelude as P The following are terrible names: T C Not to mention that this usage is hideously confusing while looking at the haddock docs. But that will be resolved when Haddock can show identifiers with qualifications. While I don't mind Haskore having them, they should just be different names for a type that has a clear name. It also appears to generate an excessive amount of modules. It's good to have fine grained modules, because you can more easily exchange the parts you want different from the standard way. For reducing import lists for simple songs I think we could provide wrapper modules. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Design your modules for qualified import
On Jun 6, 2008, at 12:54 PM, Henning Thielemann wrote: On Fri, 6 Jun 2008, Achim Schneider wrote: Jan-Willem Maessen [EMAIL PROTECTED] wrote: There's one caveat: Always choose descriptive names, even if you are assuming that you will usually use a qualified import. The following are wonderful names, even though they conflict with the prelude: null filter map lookup import Prelude as P Precisely. If I import the prelude qualified and your library unqualified, is my code readable? I should hope it is. And if the library used the overlapping names reasonably, you shouldn't be left wondering when you read my code. The following are terrible names: T C Not to mention that this usage is hideously confusing while looking at the haddock docs. But that will be resolved when Haddock can show identifiers with qualifications. I specifically *didn't* bring up the Haddock issue, because I think it's a side show. Fundamentally, these types are neither clear nor descriptive. Their treatment by one or another documentation tool is, at some level, beside the point. It's good to have fine grained modules, because you can more easily exchange the parts you want different from the standard way. For reducing import lists for simple songs I think we could provide wrapper modules. Make your modules as small as you like; small modules are great. But keep things readable, please! -Jan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
