> I completely agree with Thomas Hallgren's message. I also view the IO
> monad as a temporary solution and regret that research into better lazy
> IO seems to have stoped.
Well, not everywhere. Since noone else has mentioned it so far,
it is worth throwing in the obligatory reference to the Softw
John Meacham wrote:
personally, I think the easiest solution would be to punt the whole
issue by having:
getContents
lazily read the file if it is mmapable or a pipe
eagerly slurp the whole file if it refers to a tty
I think this kind of irregular behaviour would make the IO functions
even m
John Meacham wrote:
On Thu, Oct 02, 2003 at 12:08:07PM +0100, Nicholas Nethercote wrote:
This is because strict evaluation is always easy to understand.
Lazy/non-strict evaluation can be non-intuitive/confusing/surprising, even
for people who are used to it.
what is easy or confusing and w
On Thu, Oct 02, 2003 at 11:48:29AM +0100, Simon Marlow wrote:
> So... you agree that getContents in its current form should really be
> called unsafeGetContents? Unless perhaps we redefine its semantics to
> either (a) yield a random string or (b) eagerly slurp the entire stream
> contents?
perso
On Thu, Oct 02, 2003 at 12:08:07PM +0100, Nicholas Nethercote wrote:
> But I can't imagine they would complain about the problem of being
> confused... "this strict code evaluated immediately, what's going on?!" :)
> This is because strict evaluation is always easy to understand.
> Lazy/non-strict
> So... you agree that getContents in its current form should really be
> called unsafeGetContents? Unless perhaps we redefine its semantics to
> either (a) yield a random string or (b) eagerly slurp the entire stream
> contents?
Well, I'm not sure that the semantics of getContents is currently
On Thu, 2 Oct 2003, Thomas Johnsson wrote:
> I'm convinced that if laziness (or call by name) were the norm in
> languages in general, then there would be similar traffic
> in lists like this one about the problems of strict evaluation -- and
> there would be a lot more of it,
> since strictness c
Nicholas Nethercote wrote:
Also, I'm not convinced that laziness does make users' lives easier --
witness a lot of the traffic on this list. Witness the subject of this
thread. In which case the extra difficulty heaped upon compiler writers
is of questionable value.
I'm convinced that if lazines
On Thu, 2 Oct 2003, Nicholas Nethercote wrote:
> I appreciate the prefer-users'-ease-over-compiler-writers' idea. For
> example, syntactic sugar can be a great thing. But I think there's a
> point where it becomes too much. Haskell has arguably passed that point.
Sorry, this was ambiguous; wh
> > The real problem is that lazy I/O injects side effects into the pure
> > world of expressions. Haskell has a perfectly good system for
> > encapsulating side effects - the IO monad. So why put
> these sneaky side
> > effects into pure values?
>
> I fear one problem is that the word "side
On Thu, 2 Oct 2003, Wolfgang Jeltsch wrote:
> Yes, but I think that the reason for laziness is not to make compiler
> constructors' lifes easier but language users'.
I appreciate the prefer-users'-ease-over-compiler-writers' idea. For
example, syntactic sugar can be a great thing. But I think t
Simon Marlow wrote:
> So, we're agreed that the presence of lazy evaluation makes implementing
> optimistic evaluation (and other evaluation strategies) more
> complicated. Personally, I find it disturbing that the presence of this
> family of library functions affects something as low-level as t
Am Donnerstag, 2. Oktober 2003, 10:52 schrieb Nicholas Nethercote:
> On Wed, 1 Oct 2003, Robert Ennals wrote:
> > Haskell is a good language, pureness is good, type classes are good,
> > monads are good - but laziness is holding it back.
>
> Hear hear.
>
> I have often wondered how much simpler the
On Wed, 1 Oct 2003, Robert Ennals wrote:
> Haskell is a good language, pureness is good, type classes are good,
> monads are good - but laziness is holding it back.
Hear hear.
I have often wondered how much simpler the various Haskell implementations
would be if they used strict evaluation. It
> Yes, the presence of lazy IO makes optimistic evaluation more
> complicated, but I do not see that it compromises the purity of the
> language in anyway (whatever purity is ;-).
So, we're agreed that the presence of lazy evaluation makes implementing
optimistic evaluation (and other evaluation s
Robert Ennals wrote:
> It is wrong for all the same reasons that unsafePerformIO is wrong, except
> that it is worse than that because unsafePerformIO has "unsafe" in the title,
> and people are discouraged from using it without due care. By contrast,
> "interact" and "getContents" are presented as
Simon Marlow wrote:
> Certainly you can observe non-strictness, that's not the point. The point is that
> you can also observe more than just non-strictness using interact, and I don't think
> that is desirable. For example:
>
> interact (\xs -> let z = length xs in "Hello World\n")
>
> Now
[snip]
> Certainly you can observe non-strictness, that's not the point. The point is
> that you can also observe more than just non-strictness using interact, and I
> don't think that is desirable. For example:
>
> interact (\xs -> let z = length xs in "Hello World\n")
>
> Now, Haskell is
[ taking this one to haskell-café... ]
> I still do not quite agree with Simon that 'interact' exposes anything
> but non-strictness. Non-strictness means that
>
> map toUpper _|_ = _|_
> map toUpper ('a':_|_) = ('A':_|_)
> map toUpper ('a':'b':_|_) = ('A':'B':_|_)
>
> and 'interact (map t
19 matches
Mail list logo
