Re: Why the Prelude must die
I agree, I think this is what we need. Plus a decision of what names the builtin syntax refers to, like the type of 'a'. -- Lennart On Mar 26, 2007, at 23:30 , Ashley Yakeley wrote:
Sebastian Sylvan wrote:
The solution is simple: * If there is a "module M where" clause in the beginning of the file, then it's a "proper" module and shouldn't import the Prelude. * If there is no module declaration then it's a "quick'n dirty script" and should have the Prelude implicitly imported. * Interactive interpreters should probably import the Prelude. That should take of most issues.
I think this is ideal. I've always thought writing "import Prelude" was a good idea if one wants one's module to import the Prelude. It's one less corner case.
-- Ashley Yakeley
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Gut feeling: the quick'n dirty script case occurs far less than the
whole module case. Thus I think the benefit of automatically importing
the Prelude if the module declaration is omitted should not happen:
the Principle of Least Surprise out-weighs the small benefit to a rare
case.
Correct me if I'm wrong about my hunch that the quick'n dirty case is
rare. Even so, I have a healthy respect both for Least Surprise and a
minimal number of behaviors when it comes to compilers.
My vote would be to never automatically import the Prelude, at least
not by default.
Regarding type variable naming, a few of my more hardware minded
friends I've asked to try Haskell often tease me about the opaque type
variable names in the Prelude--it seems greater consideration of type
variable names in the Prelude might behoove new users.
On 3/27/07, Lennart Augustsson
I agree, I think this is what we need. Plus a decision of what names the builtin syntax refers to, like the type of 'a'.
-- Lennart
On Mar 26, 2007, at 23:30 , Ashley Yakeley wrote:
Sebastian Sylvan wrote:
The solution is simple: * If there is a "module M where" clause in the beginning of the file, then it's a "proper" module and shouldn't import the Prelude. * If there is no module declaration then it's a "quick'n dirty script" and should have the Prelude implicitly imported. * Interactive interpreters should probably import the Prelude. That should take of most issues.
I think this is ideal. I've always thought writing "import Prelude" was a good idea if one wants one's module to import the Prelude. It's one less corner case.
-- Ashley Yakeley
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On 27-mrt-2007, at 20:17, Nicolas Frisby wrote:
Gut feeling: the quick'n dirty script case occurs far less than the whole module case. Thus I think the benefit of automatically importing the Prelude if the module declaration is omitted should not happen: the Principle of Least Surprise out-weighs the small benefit to a rare case.
In my experience quick'n'dirty scripts tend to end up as full-blown modules later on in their life. This, to me, is a strong indication to make importing the prelude explicit. Furthermore, the arguments against explicit importing seem to be easier teaching and shorter code, as one needs much of the Prelude almost everywhere. However, Java seems to offer a reasonable datapoint in this argument: almost everything in the language needs to be explicitly imported, but for java.lang. Ofcourse, java.lang is quite annoyingly big... so a good example it is not.
Regarding type variable naming, a few of my more hardware minded friends I've asked to try Haskell often tease me about the opaque type variable names in the Prelude--it seems greater consideration of type variable names in the Prelude might behoove new users.
Good point. It would also make the Prelude sources (and Haddock docs) *much* easier to understand. Doei, Arthur. -- /\ / | arthurvl@cs.uu.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching
Nicolas Frisby wrote:
Regarding type variable naming, a few of my more hardware minded friends I've asked to try Haskell often tease me about the opaque type variable names in the Prelude--it seems greater consideration of type variable names in the Prelude might behoove new users.
I think that single letter names are very a good idea for most of the things in the Prelude. 'a', 'b' etc. are good for very general things like the basic classes (Eq, Num, etc) and for parametric functions (flip, (.), etc). I also like the 'm' for Monads of all kinds, but I would suggest to use 'mt' for monad transformers. For collections I think 'c' is nice and 'k' for keys seems to be sort of standard, but I would like to propose using 'e' as generic name for elements of collections, if there are more element types, then 'e1', e2' etc. There are more complicated cases where a multi-letter name seems apropriate, but there appear to me none of them in the Prelude. Cheers Ben
Hi
Regarding type variable naming, a few of my more hardware minded friends I've asked to try Haskell often tease me about the opaque type variable names in the Prelude--it seems greater consideration of type variable names in the Prelude might behoove new users.
I think that single letter names are very a good idea for most of the things in the Prelude. 'a', 'b' etc. are good for very general things like the basic classes (Eq, Num, etc) and for parametric functions (flip, (.), etc). I also like the 'm' for Monads of all kinds, but I would suggest to use 'mt' for monad transformers. For collections I think 'c' is nice and 'k' for keys seems to be sort of standard, but I would like to propose using 'e' as generic name for elements of collections, if there are more element types, then 'e1', e2' etc.
Looking through the Hoogle logs, if people search for a multi-letter type name, they are usually getting the wrong end of the stick. People often search for: char -> bool I don't think there is anything wrong with single letter type names, unless you are making your types too complex. Thanks Neil
participants (5)
-
Arthur van Leeuwen -
Benjamin Franksen -
Lennart Augustsson -
Neil Mitchell -
Nicolas Frisby