has been updated, now contains descriptions of the top-level names in the hierarchy, and some text in the programming conventions section (mostly copied over from the hslibs docs). Cheers, Simon
Simon Marlow wrote:
has been updated, now contains descriptions of the top-level names in the hierarchy,
I notice you have gone for a "Numeric" category, rather than the "Mathematics" top-level category suggested by Dylan. I know there hasn't been much discussion about the layout and contents of the specifically mathematical parts of the hierarchy, but Dylan's is the only current proposal from anyone who claims to know the subject in depth. :-) My instinct would be to go with the more general "Mathematics", whatever we later decided to put inside it. Regards, Malcolm
Malcolm Wallace
I notice you have gone for a "Numeric" category, rather than the "Mathematics" top-level category suggested by Dylan.
While pondering what else we'd put in mathematics other than numeric stuff, I hit upon the crazy idea of adding: Mathematics.Monad instead of putting Monad in Control (which is the current proposal, I believe). For: o it is accurate o monads which have nothing to do with control (List, Maybe, Parser?) will fit in quite nicely Against: o the Haskell learning curve gets even steeper o There's a bit of a conflict between being easy to use and being mathematically pure (e.g., Num is almost a ring but not quite (fromInteger springs to mind)). If we put things in Mathematics, the mathematicians have a strong argument for doing things the "Right Way" but if we leave it in Control, then the pragmatists retains some, ummm, control. I'm not sure myself if I think this is a good thing but I thought I'd throw it out and see if anyone else likes it enough to pick up. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/ ps Irrespective of this, I think Mathematics is a good idea because sooner or later, someone is going to add matrix ops, rings, monoids, categories, etc. to the library and they will want a place to hold them.
On Thu, May 31, 2001 at 04:27:14PM -0600, Alastair David Reid wrote:
While pondering what else we'd put in mathematics other than numeric stuff, I hit upon the crazy idea of adding:
Mathematics.Monad
instead of putting Monad in Control (which is the current proposal, I believe).
I'd vote against this. Monads are not terribly prominent in mathematics. They're used in category theory, but the reason they're in Haskell is because of their usefulness as a control structure.
o There's a bit of a conflict between being easy to use and being mathematically pure (e.g., Num is almost a ring but not quite (fromInteger springs to mind)). If we put things in Mathematics, the mathematicians have a strong argument for doing things the "Right Way" but if we leave it in Control, then the pragmatists retains some, ummm, control.
As a side note, "fromInteger" is just fine and belongs with rings. (See earlier posts). I'm much more annoyed by "abs" and "signum", not to mention the name "Num" and the inheritance from "Show" (and "Eq"). But that's all irrelevant to the current discussion, except that I support anything that leads to doing things the "Right Way". :-)
ps Irrespective of this, I think Mathematics is a good idea because sooner or later, someone is going to add matrix ops, rings, monoids, categories, etc. to the library and they will want a place to hold them.
Hmm. Reading this list, categories don't seem to fit that well. On reflection, "Mathematics" is extremely broad; perhaps too broad. Maybe "Algebra" is better? --Dylan Thurston
Dylan Thurston wrote (on 31-05-01 18:50 -0400):
On Thu, May 31, 2001 at 04:27:14PM -0600, Alastair David Reid wrote:
While pondering what else we'd put in mathematics other than numeric stuff, I hit upon the crazy idea of adding:
Mathematics.Monad
instead of putting Monad in Control (which is the current proposal, I believe).
I'd vote against this. Monads are not terribly prominent in mathematics. They're used in category theory, but the reason they're in Haskell is because of their usefulness as a control structure.
I would also oppose this, but for different reasons. First, I think it is too early to put anything into Mathematics. There ought to be some more formal standards for what goes in and what doesn't and how its innards are arranged and named. For example, I can imagine several different ways of encoding mathematical constructs in Haskell: as in Monad, where you use a Curry-Howard-et al.-style correspondence---so, you have sets/objects/propositions as types and functions/arrows/proofs as terms; as in a metacircular interpreter or symbolic manipulation package, where you collapse these two levels; as above, but for a three-level structure with type classes or kinds encoding the third level (say 2-categories). And then, as Jan pointed out, there are often many algorithms, especially for the less foundational, continuous stuff. Second, as everybody knows, there is nothing in Monad which forces user-defined instances to be monads in the mathematical sense. Whether such things belong in Mathematics may be open to argument. For example, you might want to put the class definition outside Mathematics, but the standard instances in (to `certify' them).
Hmm. Reading this list, categories don't seem to fit that well. On reflection, "Mathematics" is extremely broad; perhaps too broad. Maybe "Algebra" is better?
I think it's too broad also; what parts of mathematics are "blessed" enough to be put in Mathematics? By the C-H correspondence, every program is a piece of mathematics in some sense. I have no better suggestion. Maybe someone can give a list of examples of things that are intended to go into Mathematics...? -- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-3261 Fax +31 (030) 251-379
participants (5)
-
Alastair David Reid -
Dylan Thurston -
Frank Atanassow -
Malcolm Wallace -
Simon Marlow