Re: Shrinking the Prelude: The "categorical" approach
so the main issues are these: Bulat Ziganshin raised: Num is intrinsically bound to the compiler. sad. so let's leave Num out. this basically means we will avoid "abstract algebra" in general. that is, forget "groups", "rings", for now, the principle focus will be "functor", "monad"... Henning Thielemann provided links to CAL: hi Henning, would you mind if we "steal" some of the good looking names in your Prelude? Brian Hulley raised one serious issue: even if we were to define a "newbie" friendly Prelude, which should be preferred, alphanumeric names or operators? I have a thing for operators, they look good! but Brian's issue is solid, the precedence isn't documented by Haddock. any Haddock developer reading this? so mplus stays. I would still suggest plus/zero over mplus/zero but Haskell's scoping is rather liberal. I suggest the convention that Control.Monad is always imported as M. this would mean we use M.plus, M.zero, M.lift and so on. Diego Navarro said: this will confuse beginners. I disagree. I think type classes and monads are the basics of Haskell (before that, it's just commonsense ;)... ) so if the error message successfully conveys the message that there's a problem, that should be enough to inspire the beginner to start on the basics. besides, people will ultimately use the standard Prelude. what I am trying to do is to prove that with a good choice of names programs written in Haskell can look more "comprehensible" to beginners. like Gosling said about Java, the language syntax has one very good property: it's easy to read it. Garrett Morris seems to agree with me on this. Greg Fitzgerald raised the further issue of monads being overlooked by the beginners. I think "do notation considered harmful" blog was at least partially right: it's better to expose the concept rather than hiding it. so with enough people interested (I assume) it's time to move this discussion to the wiki. the wiki code is not to be taken seriously, it's a "proof-of-concept", a "guideline". cheers! Imam __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Wed, 20 Dec 2006, Imam Tashdid ul Alam wrote:
Bulat Ziganshin raised: Num is intrinsically bound to the compiler. sad. so let's leave Num out. this basically means we will avoid "abstract algebra" in general. that is, forget "groups", "rings", for now,
See http://www.haskell.org/haskellwiki/Libraries_and_tools/Mathematics#Type_clas...
Henning Thielemann provided links to CAL: hi Henning, would you mind if we "steal" some of the good looking names in your Prelude?
You have to direct this question to the CAL inventors. :-) Indeed I'd preferred if they had written an alternative Prelude for Haskell and a Java byte code back-end rather than hacking an independent language.
I suggest the convention that Control.Monad is always imported as M. this would mean we use M.plus, M.zero, M.lift and so on.
Seconded! About the question, whether functions should be provided in the most general context, I refer to http://www.haskell.org/haskellwiki/Slim_instance_declaration
On Thu, Dec 21, 2006 at 07:16:16PM +0100, Henning Thielemann wrote:
About the question, whether functions should be provided in the most general context, I refer to http://www.haskell.org/haskellwiki/Slim_instance_declaration
Certainly we all agree that a module that defines instances should export functions it uses that others can use in defining further instances, but I don't see the point of this rule as stated. What would we gain if Ratio exported (+) on rationals with a different name? Surely the important thing is the reusable auxiliary functions, if any, since the specialized method itself is available.
hi guys, there's a page on the haskellwiki (called "The Other Prelude") now which has a discussion page as well (like all wiki pages!). so let's do it. on topic: this is why I think renaming is quite unnecessary. The Other Prelude should be very concise, both conceptually and in size. IMHO this should increase the ease of use. for someone who is new to Haskell, this prelude itself should introduce him/her to the core concepts. Ease of (expert) use should be provided by the other modules in the package. I think in a sense, it would make a lot of sense to include only those in the Prelude which are important enough to go into the language report. it's sort of obvious that the report does not do justice to the concept of monad in the library, and wastes space discussing fairly obvious functions. let's move the discussion to the wiki discussion page. contributors needed for a "great" collaborative effort. ;) cheers! Imam Ross Paterson wrote:
On Thu, Dec 21, 2006 at 07:16:16PM +0100, Henning Thielemann wrote:
About the question, whether functions should be provided in the most general context, I refer to http://www.haskell.org/haskellwiki/Slim_instance_declaration
Certainly we all agree that a module that defines instances should export functions it uses that others can use in defining further instances, but I don't see the point of this rule as stated. What would we gain if Ratio exported (+) on rationals with a different name? Surely the important thing is the reusable auxiliary functions, if any, since the specialized method itself is available.
-- View this message in context: http://www.nabble.com/Shrinking-the-Prelude%3A-The-%22categorical%22-approac... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
On Thu, 21 Dec 2006, Ross Paterson wrote:
On Thu, Dec 21, 2006 at 07:16:16PM +0100, Henning Thielemann wrote:
About the question, whether functions should be provided in the most general context, I refer to http://www.haskell.org/haskellwiki/Slim_instance_declaration
Certainly we all agree that a module that defines instances should export functions it uses that others can use in defining further instances, but I don't see the point of this rule as stated. What would we gain if Ratio exported (+) on rationals with a different name?
(+) is probably not a convincing example. E.g. the Functor method 'fmap' is instantiated by 'map' for lists. The monad method (>>=) for lists is implemented by (flip concatMap). Shall we hide concatMap because (>>=) is already there? I say no, because in cases where lists are the only possible choice, 'map' and 'concatMap' are more informative to the reader and let automatic type inference work better than 'fmap' and (>>=). Imagine the Monad concept is still not invented. Then we could only define 'concatMap' but not '(>>=)'. Later the Monad class is introduced. Shall we discourage the use of 'concatMap' because there is now also (>>=)? Now imagine we encounter an even more general concept, where monads are a special case of. Shall we hide the more restrictive Monad method (>>=) and the plain implementation 'concatMap' in favour of the more general method?
participants (3)
-
Henning Thielemann -
Imam Tashdid ul Alam -
Ross Paterson