[Haskell-cafe] Numeric Prelude and identifiers (Was: fad 1.0 -- Forward AutomaticDifferentiation library)
On Sun, 5 Apr 2009, Kalman Noel wrote: Henning Thielemann schrieb: with advanced type classes: http://hackage.haskell.org/packages/archive/numeric-prelude/0.0.5/doc/html/MathObj-PowerSeries.html I'll take this as another opportunity to point out that the Haddock docs of the Numeric Prelude are highly unreadable, due to all qualified class and type names appearing as just C or T. It's Haddock's fault. :-) I have written a Trac ticket, but trac.haskell.org does currently not respond. I'm wondering, too, if the Numeric Prelude could be organized more cleanly if we had a fancier module system - does someone have sufficient experience with, say, ML-style module systems to tell? Are you complaining about the organisation or about the identifiers? If you mean the former, then what organisation do you propose? If you mean the latter ... Many proposals about extended import facilities I saw were complicated and could simply be avoided using the naming style I use. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Numeric Prelude and identifiers (Was: fad 1.0 -- Forward AutomaticDifferentiation library)
On Apr 5, 2009, at 9:33 AM, Henning Thielemann wrote: On Sun, 5 Apr 2009, Kalman Noel wrote: Henning Thielemann schrieb: with advanced type classes: http://hackage.haskell.org/packages/archive/numeric-prelude/0.0.5/doc/html/MathObj-PowerSeries.html I'll take this as another opportunity to point out that the Haddock docs of the Numeric Prelude are highly unreadable, due to all qualified class and type names appearing as just C or T. It's Haddock's fault. :-) I have written a Trac ticket, but trac.haskell.org does currently not respond. I may be treading in murky waters here, but I do think a large part of the problem is that the Numeric Prelude has chosen to use ML naming conventions (which refer to types in a module as T, etc.) when you're writing a Haskell program. Surely if the types, classes, and so forth were given evocative names, numeric prelude programs would become readable? And as a special bonus, though it may offend your sensibilities, numeric prelude programs might be able to use unqualified import in certain circumstances? -Jan-Willem Maessen [For each language, its own idiom!] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
