Re: [Haskell-cafe] ANNOUNCE: fad 1.0 -- Forward Automatic Differentiation library
Henning Thielemann schrieb:
with advanced type classes: http://hackage.haskell.org/packages/archive/numeric-prelude/0.0.5/doc/html/M...
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. 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? Kalman
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/M...
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.
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/M...
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!]
Henning Thielemann schrieb:
On Sun, 5 Apr 2009, Kalman Noel wrote:
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?
I'm not complaining, and I'm not sure what I mean :) I may like a scheme where functions operating on a type or type class live in a module seperate from the type (class) definition, so you could import a specific module to get only, say, (Ring, (*), one, ...). But that would be too tedious in the Haskell hierarchical module system, which is why I was asking about others.
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.
I'm ready to believe you that the naming style you chose is optimal within the hierarchical module system. Regards, Kalman
On Mon, 6 Apr 2009, Kalman Noel wrote:
I'm not complaining, and I'm not sure what I mean :) I may like a scheme where functions operating on a type or type class live in a module seperate from the type (class) definition, so you could import a specific module to get only, say, (Ring, (*), one, ...). But that would be too tedious in the Haskell hierarchical module system, which is why I was asking about others.
It was precisely my goal to bundle the type with the functions that operate on it. Why do you want to separate them?
Henning Thielemann schrieb:
On Mon, 6 Apr 2009, Kalman Noel wrote:
I'm not complaining, and I'm not sure what I mean :) I may like a scheme where functions operating on a type or type class live in a module seperate from the type (class) definition, so you could import a specific module to get only, say, (Ring, (*), one, ...). But that would be too tedious in the Haskell hierarchical module system, which is why I was asking about others.
It was precisely my goal to bundle the type with the functions that operate on it. Why do you want to separate them?
Sorry for the huge delay. Here are some reasons why I think such a seperation can be handy: (1) If I need an import just to be able to write a type annotation (e.g. I'm passing around a value of that type, but not doing anything specific to it), then I can just import a module that gives me the relevant types. (2) Similarly, I can, say, calculate with complex numbers and refer to them as Complex Double without importing (qualified) the Complex implementations of exp, signum etc., which I won't ever have to use directly, thanks to the relevant type class instances. (3) I can refer to a Ring as a Ring, rather than a Ring.C. (1) may not be so important, given that I can just write an import list. (2) means seperating interface and implementation (without hiding the implementation). (3) is just a matter of taste.
participants (3)
-
Henning Thielemann -
Jan-Willem Maessen -
Kalman Noel