Difference between revisions of "Talk:The Other Prelude"

From HaskellWiki
Jump to navigation Jump to search
m (join vs concat)
m (question on (>>=))
Line 15: Line 15:
 
* I propose operators to be preferred over alphanumeric names. <hask>(++)</hask> seems way cooler than <hask>M.plus</hask>. YMMV. Vote here. About the precedence issue, I think proper usage of parentheses is enough for all practical purposes. Besides, (++) is associative.
 
* I propose operators to be preferred over alphanumeric names. <hask>(++)</hask> seems way cooler than <hask>M.plus</hask>. YMMV. Vote here. About the precedence issue, I think proper usage of parentheses is enough for all practical purposes. Besides, (++) is associative.
 
* <hask>join</hask> is the same as more specific <hask>concat</hask> as far as I get it. The task it accomplishes is more accurately described by the English word "join" than pseudoEnglish "concat". I think there should be no "concat" at all. One of the principle goals of this project is reducing the API.
 
* <hask>join</hask> is the same as more specific <hask>concat</hask> as far as I get it. The task it accomplishes is more accurately described by the English word "join" than pseudoEnglish "concat". I think there should be no "concat" at all. One of the principle goals of this project is reducing the API.
  +
* This is basically a question... (>>=) is equivalent to <hask>concatMap</hask> in the list monad. I am not exactly a fan of the name, the Scala community uses <hask>flatMap</hask> as far as I recall. Should we include the function <hask>flatMap</hask> in the monad? Has one advantage, sometimes it's intuitive. I reckon it's intuitive whenever (=<<) is.
 
--[[User:Uchchwhash|Pirated Dreams]] 12:38, 28 December 2006 (UTC)
 
--[[User:Uchchwhash|Pirated Dreams]] 12:38, 28 December 2006 (UTC)

Revision as of 13:58, 28 December 2006

i have no idea what i'm talking about here, but shouldn't "Monad m" imply "Functor m" if we're already starting with a clean slate? Also, what should the solution to "head", etc be? --Johannes Ahlmann 09:47, 21 December 2006 (UTC)

"Monad m" should imply "Functor m". By your question about "head", do you mean the problem of it being undefined on []? BrettGiles 14:13, 21 December 2006 (UTC)
head, fst et cetera are projection functions. They can, in fact, be achieved by pattern matching, and are done that way often. It seems to me that at least the Prelude should be very mathematical and leave them out. YMMV. But Monad m should really imply Functor m if we want to be mathematical, and indeed we do. --Pirated Dreams 22:33, 21 December 2006 (UTC)
I'm not so sure whether you can just leave projections out of the prelude and it definitely wouldn't solve the underlying problem. Also I'd love to see some functions from MissingH (especially a sensible "split") in the prelude. Furthermore there's the question which functions from other libraries should be exported by Prelude (either, list functions, error/catch, fail, fmap, IO functions, mapM, maybe, read/reads, sequence, Numeric functions, ...). There definitely has to be some discussion about the necessity of including some of these. --Johannes Ahlmann 12:34, 23 December 2006 (UTC)

Naming

Although the name of the page "The Other Prelude" does not seem to fit the Wiki standard (sentence case says: The other prelude), I left it as it appears to be a proper name when you read the content. BrettGiles 14:13, 21 December 2006 (UTC)

Yes Brett, at least that was my intention. --Pirated Dreams 22:33, 21 December 2006 (UTC)

Issues

I propose the following:

  • The Functor hierarchy proposal should be adopted.
  • There will be basic algebra modules in the Prelude hierarchy. Named, possibly, TheOtherPrelude.Algebra, if the numerical prelude people are happy with it. At this point I think the name, though clear, is very long.
  • I propose operators to be preferred over alphanumeric names. (++) seems way cooler than M.plus. YMMV. Vote here. About the precedence issue, I think proper usage of parentheses is enough for all practical purposes. Besides, (++) is associative.
  • join is the same as more specific concat as far as I get it. The task it accomplishes is more accurately described by the English word "join" than pseudoEnglish "concat". I think there should be no "concat" at all. One of the principle goals of this project is reducing the API.
  • This is basically a question... (>>=) is equivalent to concatMap in the list monad. I am not exactly a fan of the name, the Scala community uses flatMap as far as I recall. Should we include the function flatMap in the monad? Has one advantage, sometimes it's intuitive. I reckon it's intuitive whenever (=<<) is.

--Pirated Dreams 12:38, 28 December 2006 (UTC)