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
Bruce,
All this discussion of 'interact' makes me feel quite nostalgic. In
the late 80s(!) I did some work on this, since Miranda's only IO was in
the form of interact. Understanding the interleaving behaviour is
problematic, and hand-coded solutions proved to be difficult. I came up
with a way
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
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 various
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 the
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
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 effect is
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; when
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
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
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, 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
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?
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
I wrote:
main=interact id basically echoes every line of my input, whereas
main=interact show correctly waits for EOF before
outputting something.
The unix cat and sort behave in a similar way (sort obviuously has
to wait for the last line.)
Still I would regard it to be more pure (or abstract)
On Tue, Sep 30, 2003 at 03:52:50PM +0200, Christian Maeder wrote:
Hi,
For GHC (6.0.1)
main=interact id basically echoes every line of my input, whereas
main=interact show correctly waits for EOF before outputting something.
That's only because output to terminal is line buffered by
Christian Maeder [EMAIL PROTECTED] writes:
I guess interact does what it should, but I think it should be changed
to avoid interleaved in- and output.
Surely the name suggests that interactive behaviour is required, i.e.
exactly some interleaving of input and output. The chunk-size of the
main=interact id basically echoes every line of my input, whereas
main=interact show correctly waits for EOF before outputting something.
What should a student think about interact in the Prelude? (It's ok
for pipes only, I guess.)
main = interact show
behaves similar to
main = interact
Malcolm Wallace wrote:
[...]
Surely the name suggests that interactive behaviour is required, i.e.
exactly some interleaving of input and output. The chunk-size of the
interleaving should depend only on the strictness of the argument to
interact.
I'm not happy that interleaving depends on the
Christian Maeder [EMAIL PROTECTED] writes:
I'm not happy that interleaving depends on the strictness. Lazy or
strict evaluation should only change the behaviour of overall
termination (lazy evaluation should terminate more often).
But the whole purpose of 'interact' is to use its argument
Christian Maeder wrote:
Malcolm Wallace wrote:
[...]
Surely the name suggests that interactive behaviour is required, i.e.
exactly some interleaving of input and output. The chunk-size of the
interleaving should depend only on the strictness of the argument to
interact.
I'm not
Christian Maeder wrote:
Malcolm Wallace wrote:
[...]
Surely the name suggests that interactive behaviour is required, i.e.
exactly some interleaving of input and output. The chunk-size of the
interleaving should depend only on the strictness of the argument to
interact.
I'm not happy that
Christian Maeder wrote:
Colin Runciman wrote:
Let not the eager imperative tail wag the lazy functional dog!
Ideally functional programs should be independent of evaluation strategy
and I assume that this is the case for about 90% of all Haskell
programs. This leaves maybe the head or only
Malcolm Wallace writes:
But the whole purpose of 'interact' is to use its argument as the
demanding function which drives lazy consumption of the input. It is
*designed* to reveal the evaluation behaviour, by hoisting it into
the I/O monad.
This is why interact is bad, IMO: it forces you to
But looking at the two actions of interact:
interact f = do
s - getContents
putStr (f s)
(The Haskell report has two more actions, btw, setting nobuffering here)
I would expect the first action to be finished before the second, (and I
Why?
The magic here, in any case, is in
Simon Marlow wrote:
Malcolm Wallace writes:
But the whole purpose of 'interact' is to use its argument as the
demanding function which drives lazy consumption of the input. It is
*designed* to reveal the evaluation behaviour, by hoisting it into
the I/O monad.
This is why interact
Simon Marlow wrote:
| For example, eager evaluation would be a completely
| valid implementation strategy for Haskell if it were
| not for lazy I/O.
I do not understand this remark.
As far as I know, in any valid implementation of Haskell,
the following expression:
const 3 undefined
Pardon? Haskell is a non-strict language. Using 'interact' is one of
numerous situations where one takes advantage of non-strict semantics.
(Keith just gave a different example.)
Non-strict semantics does not prescribe the evaluation order, although
usually lazy evaluation is used. I
[snip]
No, optimistic evaluation does not work well with interact, because it
causes the input stream to be evaluated (and therefore demanded) earlier
than you would expect. This is the problem: interact exposes more than
just non-strictness, it exposes laziness.
In Robert Ennals'
Robert Ennals wrote:
No, optimistic evaluation does not work well with interact, because it
causes the input stream to be evaluated (and therefore demanded) earlier
than you would expect. This is the problem: interact exposes more than
just non-strictness, it exposes laziness.
In
I wrote:
But looking at the two actions of interact:
interact f = do
s - getContents
putStr (f s)
I would expect the first action to be finished before the second
Keith Wansbrough wrote:
Why?
Because the actions are written down in that order? Why not? Why should
I expect pipelining?
On Wed, Oct 01, 2003 at 04:42:51PM +0200, Christian Maeder wrote:
Can actually someone supply an implementation of something like interact
that does no pipelining for the argument id? Simply doing putStr !$ f
!$ s was not enough!
The simplest working but not necessarily correct solution
Allow me to have another opinion, if the consequence is interleaved in-
and output (when I don't want it).
Can actually someone supply an implementation of something like interact
that does no pipelining for the argument id? Simply doing putStr !$ f
!$ s was not enough!
Yes, of course.
On Wed, 1 Oct 2003, Keith Wansbrough wrote:
Can actually someone supply an implementation of something like interact
that does no pipelining for the argument id? Simply doing putStr !$ f
!$ s was not enough!
Yes, of course.
Your code above only forces the evaluation of the first
Can actually someone supply an implementation of something like interact
that does no pipelining for the argument id? Simply doing putStr !$ f
!$ s was not enough!
Yes, of course.
Your code above only forces the evaluation of the first cons-cell of
the list, which is not enough. You want to
On the pedagogic part of this issue, I personally feel that using interact
causes concentration on the temporal logic aspects of the code. That is,
on understanding the interaction between the computer and the user as a
whole. Although the monad approach has this in it, I feel it to be more
[ 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
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, Haskell
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 being
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
Hi,
For GHC (6.0.1)
main=interact id basically echoes every line of my input, whereas
main=interact show correctly waits for EOF before outputting something.
Furthermore the buffering mode must be LineBuffering.
If I explicitely set the buffering to NoBuffering I'm not able to
enter EOF by
main=interact id basically echoes every line of my input, whereas
main=interact show correctly waits for EOF before
outputting something.
Which of these are you claiming is wrong?
I guess interact does what it should, but I think it should be changed
to avoid interleaved in- and output.
lose
42 matches
Mail list logo
