I support both reducing the prelude to just a few commonly used combinators, and
requiring an explicit import Prelude. In response to a couple of Stefan's points:
Stefan O'Rear wrote:
6. Dependency
Because every module imports the Prelude every module that the Prelude
depends on, mutually
On blessed Wed Mar 28 05:52:03 EDT 2007 Simon Marlow wrote:
I support both reducing the prelude to just a few commonly used combinators,
and
requiring an explicit import Prelude. (...)
So YOU are the GOD's angle with the sword!
And thus we leave the orchard for a battlefield. I really
On 28/03/07, Simon Marlow [EMAIL PROTECTED] wrote:
I support both reducing the prelude to just a few commonly used combinators, and
requiring an explicit import Prelude.
Just to clear things up: would you need to do an import Prelude to get
at these few commonly used combinators, or would
mgsloan wrote:
On 3/24/07, Vivian McPhail [EMAIL PROTECTED] wrote:
I agree with Sven, but...
What I want to push is a 'mathematically sound' numeric prelude. A
proper
numerical prelude should have bona fide mathematical obects like groups,
rings, and fields underlying common numerical
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
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
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
I've submitted:
http://hackage.haskell.org/trac/haskell-prime/ticket/124
which I hope covers the essence of the result of this thread.
Thanks
Ian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On 25/03/07, Ian Lynagh [EMAIL PROTECTED] wrote:
I've submitted:
http://hackage.haskell.org/trac/haskell-prime/ticket/124
which I hope covers the essence of the result of this thread.
I'd hate to have to import things like Data.Function for such trivial
functions as (.) and ($), which
[reply-to set; dropping libraries]
On Sun, Mar 25, 2007 at 04:33:51PM +0100, David House wrote:
On 25/03/07, Ian Lynagh [EMAIL PROTECTED] wrote:
I've submitted:
http://hackage.haskell.org/trac/haskell-prime/ticket/124
which I hope covers the essence of the result of this thread.
On 25/03/07, Ian Lynagh [EMAIL PROTECTED] wrote:
You wouldn't have to import a number of different modules like
Data.Function, you could just import Prelude.
I guess what I was getting at was that Haskell is very good at
blurring the distinction between userland function and actual syntax.
On Sun, Mar 25, 2007 at 04:05:51PM +0100, Ian Lynagh wrote:
I've submitted:
http://hackage.haskell.org/trac/haskell-prime/ticket/124
which I hope covers the essence of the result of this thread.
My goal of sparking thought was sucessful :)
I like Claus Reinke's proposal, it solves
12 matches
Mail list logo
