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
hid
Is there a good reason why `exitImmediately` (in System.Posix.Process as
well as other places) shouldn't return `IO a` instead of `IO ()`?
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
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 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
> 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
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 solutio
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? Oc
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.
> >
Hello,
While trying to learn Hakell I came across a weird (to me) error message
concerning imported instance declarations.
This module
module XXX() where
import Control.Monad.Error()
instance Functor ((->)i) where
fmap = (.)
gives this error message (compiling with ghc 5.0.4
[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' i
> 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
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
shoul
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
> 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
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
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 the
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 the nose for laziness of
the
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:
>
> 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".
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 argume
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
> "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 = in
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
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
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" (o
There's another possible fix which makes use of scoped variables.
instance (RT r1 t1, RT r2 t2, TPair t t1 t2) => RT (RPair r1 r2) t where
rtId (RPair r1 r2) t = "RT (RPair " ++ rtId r1 t1 ++ " " ++ rtId r2 t2 ++")"
where (t1::t1,t2::t2) = prj t
^^
scoped vari
26 matches
Mail list logo
