Talk:The Other Prelude
From HaskellWiki
(Difference between revisions)
Nmessenger (Talk  contribs) (RE: flatMap) 

(16 intermediate revisions by 7 users not shown)  
Line 1:  Line 1:  
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? [[User:JohannesAhlmannJohannes Ahlmann]] 09:47, 21 December 2006 (UTC)  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? [[User:JohannesAhlmannJohannes 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 <hask>[]</hask>? [[User:BrettGilesBrettGiles]] 14:13, 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 <hask>[]</hask>? [[User:BrettGilesBrettGiles]] 14:13, 21 December 2006 (UTC)  
+  
:: <hask>head</hask>, <hask>fst</hask> 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 <hask>Monad m</hask> should really imply <hask>Functor m</hask> if we want to be mathematical, and indeed we do. [[User:UchchwhashPirated Dreams]] 22:33, 21 December 2006 (UTC)  :: <hask>head</hask>, <hask>fst</hask> 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 <hask>Monad m</hask> should really imply <hask>Functor m</hask> if we want to be mathematical, and indeed we do. [[User:UchchwhashPirated 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. [[User:JohannesAhlmannJohannes Ahlmann]] 12:34, 23 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. [[User:JohannesAhlmannJohannes Ahlmann]] 12:34, 23 December 2006 (UTC)  
−  ==Naming==  +  == 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. [[User:BrettGilesBrettGiles]] 14:13, 21 December 2006 (UTC)  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. [[User:BrettGilesBrettGiles]] 14:13, 21 December 2006 (UTC)  
+  
: Yes Brett, at least that was my intention. [[User:UchchwhashPirated Dreams]] 22:33, 21 December 2006 (UTC)  : Yes Brett, at least that was my intention. [[User:UchchwhashPirated Dreams]] 22:33, 21 December 2006 (UTC)  
+  
+  I propose the a rename to <hask>Prelude'</hask> for the module. Short, and parallels Haskell'. Also, I'm not fond of the name <hask>boolean</hask>. If there are no objections, I'll rename it to <hask>if'</hask> [[User:NmessengerNick Messenger]] 18:28, 4 February 2007 (UTC)  
+  :: Feel free. I named it <hask>boolean</hask> for fairly obscure reasons ;). Prelude' seems way cooler. But I guess we should keep this page and the name of the project. There's only one problem with all these: I am not sure where this would end up. I wasn't sure what I wanted to do exactly, but it seems this page has had one good impact, the class system extension proposal. But yeah, go ahead. Let the motto of this exercise be: what should the Prelude look like in Haskell'? of course, for that, Haskell' needs to get finished. to use this Prelude as a Prelude, the compiler should know about it beforehand. any YHC hacker reading this? [hint, hint] [[User:UchchwhashPirated Dreams]] 10:23, 5 February 2007 (UTC)  
== Issues ==  == Issues ==  
−  +  
−  +  
* There will be basic algebra modules in the Prelude hierarchy. Named, possibly, <hask>TheOtherPrelude.Algebra</hask>, if the numerical prelude people are happy with it. At this point I think the name, though clear, is very long.  * There will be basic algebra modules in the Prelude hierarchy. Named, possibly, <hask>TheOtherPrelude.Algebra</hask>, 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. <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.  * 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:UchchwhashPirated Dreams]] 12:38, 28 December 2006 (UTC)  [[User:UchchwhashPirated Dreams]] 12:38, 28 December 2006 (UTC)  
+  
+  :: If we really want to go for consistency, then perhaps 'joinMap'? [[User:NmessengerNmessenger]] 00:05, 4 January 2007 (UTC)  
+  
+  ::: <hask>joinMap</hask> is consistent in that is says what it does :) <hask>flatMap</hask> would have introduced it (<hask>join . map</hask>) as a bit more sophisticated ''concept'' (highlighting the map underneath the monadic container). Doesn't really matter. Thanks for pulling <hask>(>>)</hask> up. I am not aware of any caveats, though the experts may jump in and say "you see, this and that are the reasons we didn't do it ..." and ruin the day ;) [[User:UchchwhashPirated Dreams]] 11:02, 4 January 2007 (UTC)  
+  
+  : Why is <hask>const</hask> imported? Shouldn't we use <hask>return</hask> instead?  
+  
+  : I suggest using <hask>(++)</hask> for <hask>mappend</hask> instead, e.g. like Cale did [http://www.reddit.com/r/programming/comments/7cf4r/monoids_in_my_programming_language/c06adnx on Reddit showing the use of monoids]. If we also want to use <hask>(++)</hask> for <hask>mplus</hask>, we could make all <hask>MonadPlus</hask> instances an instance of <hask>Monoid</hask> as shown in [http://en.wikibooks.org/wiki/Haskell/MonadPlus Wikibooks/Haskell/MonadPlus]. [[User:RayNbowRayNbow]] 10:15, 26 November 2008 (UTC)  
+  
+  * Nuke return, make a <hask>Pointed</hask> class that defines <hask>pure</hask> and add a constraint to <hask>Monad</hask>. Likewise, a <hask>CoPointed</hask> class providing <hask>coPure</hask> (I'm serious) to replace all those <hask>runXXX</hask> functions  
+  * For <hask>Monoid</hask>, I opt for <hask>munit</hask> and <hask>mop</hask>  
+  [[User:KsfKsf]]  
+  
+  
+  == Duplicate definitions ==  
+  
+  I found out that we have been duplicating Gofer's prelude here :p  
+  
+  Also, projecting the future, I see we'll be seeing duplicate definitions in the prelude (like <hask>map</hask> and <hask>(.)</hask>). I think we can do something here. Mostly, this renaming is worthwhile for one reason: sometimes they are useful as operators, sometimes as functions. I think we should keep one of them inside the class, the other outside. This guarantees that they mean exactly the same thing. This provides cleaner documentation and consistency. If someone wants to provide an alternative defintion of <hask>(.)</hask> (say) s/he can hide it from the prelude. [[User:UchchwhashPirated Dreams]] 11:11, 4 January 2007 (UTC)  
+  
+  : should <hask><*></hask> be named <hask>*>></hask>? the current is symmetriclooking but the meaning is not. [[User:UchchwhashPirated Dreams]] 20:37, 22 January 2007 (UTC)  
+  
+  :: The <hask>Applicative</hask> class in the <hask>Control.Applicative</hask> module names this function <hask>(*>)</hask>. I'm not sure if this is better than its name in <hask>Monad</hask> or not. My current inclination is <hask>(>>)</hask> for backwards compatibility, but that's not so important in this exercise. Re: duplicate names; I've thought about this a little, and the same argument could be applied to any class that defines methods in terms of each other. <hask>(<)</hask>, <hask>(<=)</hask>, <hask>(>)</hask>, and <hask>(>=)</hask> could be lifted from <hask>Ord</hask> (and defined in terms of <hask>compare</hask>), <hask>(>>)</hask>/<hask>(*>)</hask> from <hask>Applicative</hask>, <hask>join</hask> from <hask>Monad</hask>, etc. I'm not sure where to draw the line, so I'd defer it. [[User:NmessengerNick Messenger]] 16:45, 3 February 2007 (UTC)  
+  ::: Okay, agreed. [[User:UchchwhashPirated Dreams]] 10:23, 5 February 2007 (UTC)  
+  
+  :: Reneamed it to <hask><@></hask>  
+  
+  == Unchanged ==  
+  
+  : Does Monoid remain the same? Where is MonadPlus actually useful in practice?  
+  
+  == Composition operator (.) ==  
+  
+  <hask>(.)</hask> shoudldn't be defined to be <hask>map</hask>. It should be the composition operation in a general category. Perhaps <hask><$></hask> should be the infix operator for <hask>map</hask>. [[User:RoconnorRoconnor]] 00:37, 30 November 2008 (UTC)  
+  
+  == Boolean operators ==  
+  
+  How about introducing a type class for && and  and the like?  
+  
+  instance Boolean Logic where  
+  (&&) = And  
+  () = Or  
+  : what good would that do? [[User:UchchwhashPirated Dreams]] 13:51, 17 February 2009 (UTC) 
Latest revision as of 20:11, 17 February 2009
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)[]
 ,headet 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. Butfstshould really implyMonad mif we want to be mathematical, and indeed we do. Pirated Dreams 22:33, 21 December 2006 (UTC)Functor m

 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)
Contents 
[edit] 1 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)
Prelude'
boolean
if'
 Feel free. I named it for fairly obscure reasons ;). Prelude' seems way cooler. But I guess we should keep this page and the name of the project. There's only one problem with all these: I am not sure where this would end up. I wasn't sure what I wanted to do exactly, but it seems this page has had one good impact, the class system extension proposal. But yeah, go ahead. Let the motto of this exercise be: what should the Prelude look like in Haskell'? of course, for that, Haskell' needs to get finished. to use this Prelude as a Prelude, the compiler should know about it beforehand. any YHC hacker reading this? [hint, hint] Pirated Dreams 10:23, 5 February 2007 (UTC)boolean
 Feel free. I named it
[edit] 2 Issues
 There will be basic algebra modules in the Prelude hierarchy. Named, possibly, , if the numerical prelude people are happy with it. At this point I think the name, though clear, is very long.TheOtherPrelude.Algebra
 I propose operators to be preferred over alphanumeric names. seems way cooler than(++). YMMV. Vote here. About the precedence issue, I think proper usage of parentheses is enough for all practical purposes. Besides, (++) is associative.M.plus
 is the same as more specificjoinas 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.concat
 This is basically a question... (>>=) is equivalent to in the list monad. I am not exactly a fan of the name, the Scala community usesconcatMapas far as I recall. Should we include the functionflatMapin the monad? Has one advantage, sometimes it's intuitive. I reckon it's intuitive whenever (=<<) is.flatMap
Pirated Dreams 12:38, 28 December 2006 (UTC)
 If we really want to go for consistency, then perhaps 'joinMap'? Nmessenger 00:05, 4 January 2007 (UTC)
 is consistent in that is says what it does :)joinMapwould have introduced it (flatMap) as a bit more sophisticated concept (highlighting the map underneath the monadic container). Doesn't really matter. Thanks for pullingjoin . mapup. I am not aware of any caveats, though the experts may jump in and say "you see, this and that are the reasons we didn't do it ..." and ruin the day ;) Pirated Dreams 11:02, 4 January 2007 (UTC)(>>)

 Why is imported? Shouldn't we useconstinstead?return
 I suggest using for(++)instead, e.g. like Cale did on Reddit showing the use of monoids. If we also want to usemappendfor(++), we could make allmplusinstances an instance ofMonadPlusas shown in Wikibooks/Haskell/MonadPlus. RayNbow 10:15, 26 November 2008 (UTC)Monoid
 Nuke return, make a class that definesPointedand add a constraint topure. Likewise, aMonadclass providingCoPointed(I'm serious) to replace all thosecoPurefunctionsrunXXX
 For , I opt forMonoidandmunitmop
Ksf
[edit] 3 Duplicate definitions
I found out that we have been duplicating Gofer's prelude here :p
Also, projecting the future, I see we'll be seeing duplicate definitions in the prelude (likemap
(.)
(.)
 should be named<*>? the current is symmetriclooking but the meaning is not. Pirated Dreams 20:37, 22 January 2007 (UTC)*>>
 The class in theApplicativemodule names this functionControl.Applicative. I'm not sure if this is better than its name in(*>)or not. My current inclination isMonadfor backwards compatibility, but that's not so important in this exercise. Re: duplicate names; I've thought about this a little, and the same argument could be applied to any class that defines methods in terms of each other.(>>),(<),(<=), and(>)could be lifted from(>=)(and defined in terms ofOrd),compare/(>>)from(*>),Applicativefromjoin, etc. I'm not sure where to draw the line, so I'd defer it. Nick Messenger 16:45, 3 February 2007 (UTC)Monad
 Okay, agreed. Pirated Dreams 10:23, 5 February 2007 (UTC)
 The
 Reneamed it to <@>
 Reneamed it to
[edit] 4 Unchanged
 Does Monoid remain the same? Where is MonadPlus actually useful in practice?
[edit] 5 Composition operator (.)
(.)
map
<$>
map
[edit] 6 Boolean operators
How about introducing a type class for && and  and the like?
instance Boolean Logic where (&&) = And () = Or
 what good would that do? Pirated Dreams 13:51, 17 February 2009 (UTC)