On Thu, 2009-03-05 at 23:52 +0100, Henning Thielemann wrote:
> On Wed, 4 Mar 2009, John Lato wrote:
>
> >> John A. De Goes schrieb:
> >>
> >>> Elsewhere, laziness can be a real boon, so I don't understand your
> >>> question, "Why have laziness in Haskell at all?"
> >>
> >> As I have written, many
On Wed, 4 Mar 2009, John Lato wrote:
John A. De Goes schrieb:
Elsewhere, laziness can be a real boon, so I don't understand your
question, "Why have laziness in Haskell at all?"
As I have written, many libaries process their data lazily (or could be
changed to do so without altering their i
jwlato:
> On Tue, Mar 3, 2009 at 1:03 AM, Henning Thielemann
> wrote:
> >
> > On Mon, 2 Mar 2009, John Lato wrote:
> >
> > While I think that the Iteratee pattern has benefits, I suspect that it
> > can't be combined with regular lazy functions, e.g. of type [a] -> [a]. Say
> > I have a chain of f
> John A. De Goes schrieb:
>
>> Elsewhere, laziness can be a real boon, so I don't understand your
>> question, "Why have laziness in Haskell at all?"
>
> As I have written, many libaries process their data lazily (or could be
> changed to do so without altering their interface) but their interface
On Tue, Mar 3, 2009 at 1:03 AM, Henning Thielemann
wrote:
>
> On Mon, 2 Mar 2009, John Lato wrote:
>
> While I think that the Iteratee pattern has benefits, I suspect that it
> can't be combined with regular lazy functions, e.g. of type [a] -> [a]. Say
> I have a chain of functions: read a file, p
John A. De Goes schrieb:
> Elsewhere, laziness can be a real boon, so I don't understand your
> question, "Why have laziness in Haskell at all?"
As I have written, many libaries process their data lazily (or could be
changed to do so without altering their interface) but their interface
can forbi
Lazy IO is a complete disaster for "interactive IO", such as network
and process IO. Moreover, it's somewhat of a failure even for non-
interactive IO such as the use case you described, because it's very
easy for partial evaluation to lead to unclosed files and lazy
evaluation to lead to
On Mon, 2 Mar 2009, John Lato wrote:
Hello,
I am not a super-geek (at least, not compared to others on this list),
but I'll take a try at this anyway. The benefits of iteratees mostly
depend on differences between lazy and strict IO (see ch. 7 of Real
World Haskell for more on this).
Maybe
Hi all,
thanks again for the explanation.
So I have the impression that this approach is something with recognized
merit but in a way still considered work in progress as I do not really
see it advertised for the general haskell audience.
And there are some that study it further.
Ok.
My q
On Mon, 2009-03-02 at 12:50 +, Bayley, Alistair wrote:
> > From: haskell-cafe-boun...@haskell.org
> > [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Duncan Coutts
> >
> > This can still be done using withFile and hGetContents. You
> > just have to
> > put the consumer inside the scop
On 2009 Mar 2, at 7:40, Manlio Perillo wrote:
Bayley, Alistair ha scritto:
All the file is consumed, before the result is returned.
This only works if the entire file can reasonably fit into memory.
It's not the entire file, but only the parsed data structure.
...which, depending on what yo
> From: haskell-cafe-boun...@haskell.org
> [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Duncan Coutts
>
> This can still be done using withFile and hGetContents. You
> just have to
> put the consumer inside the scope of withFile. The consumer
> can work in
> a streaming fashion. With
Bayley, Alistair ha scritto:
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Manlio Perillo
Sent: 02 March 2009 11:01
Eugene Kirpichov ha scritto:
I'm not considering the lazy IO approach, as it doesn't involve any
form of control over resources.
On Mon, 2009-03-02 at 11:50 +, Bayley, Alistair wrote:
> > From: haskell-cafe-boun...@haskell.org
> > [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Manlio Perillo
> > Sent: 02 March 2009 11:01
> >
> > Eugene Kirpichov ha scritto:
> > > I'm not considering the lazy IO approach, as it
allowed for seekable resources.
So you've managed to achieve many of the benefits of lazy IO
(composability, generality, and efficiency) without the drawbacks.
Furthermore resources are managed strictly and released as soon as
possible.
I hope this is helpful.
Cheers,
John Lato
> Me
> From: haskell-cafe-boun...@haskell.org
> [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Manlio Perillo
> Sent: 02 March 2009 11:01
>
> Eugene Kirpichov ha scritto:
> > I'm not considering the lazy IO approach, as it doesn't involve any
> > form of control over resources.
>
> This is no
Eugene Kirpichov ha scritto:
OK, I'm far from being a supergeek, but anyways.
I'm not considering the lazy IO approach, as it doesn't involve any
form of control over resources.
This is not always true.
I'm using lazy IO, still having full control over the resources.
parse path = withFile pat
OK, I'm far from being a supergeek, but anyways.
I'm not considering the lazy IO approach, as it doesn't involve any
form of control over resources.
With the traditional approach, you manually ask a stream do to
something (read a block of bytes, seek to a position etc.), and your
program is a mixt
Hi everyone,
after reading all the responses I would like to ask someone, anyone, to
kind of summarize the merits of the left-fold-enumerator approach.
From all that I read so far about it all I was able to gather was that
it has significance but I'm still not even sure what for and what not
Hi Don,
Would you please elaborate on what features or capabilities you think
are missing from left-fold that would elevate it out of the special
purpose category? I think that the conception is so completely
different from bytestrings that just saying it's not a bytestring
equivalent doesn't giv
Hello,
I'm not sure that I would call it a general-purpose resource
preserving technique. As I understand it, the general concept is a
means to handle strict data processing in a functional manner. Any
"resource preserving" that comes from this is actually from the use of
strict IO rather than l
Hi,
thank you all for your responses. I see now that the subject did indeed
register with some haskellers. :-)
I had hoped that is will eventually become the tested and approved
method for certain types of problems that do arise.
Maybe some of you have read my earlier posts that I was devel
jwlato:
> Hello Günther,
>
> I think the largest reason Haskellers don't use left-fold enumerators
> is that there isn't a ready-to-use package on Hackage. Oleg's code is
> extremely well commented and easy to follow, but it's not cabalized.
>
> In addition to Takusen, Johan Tibbe's hyena applic
Hello Günther,
I think the largest reason Haskellers don't use left-fold enumerators
is that there isn't a ready-to-use package on Hackage. Oleg's code is
extremely well commented and easy to follow, but it's not cabalized.
In addition to Takusen, Johan Tibbe's hyena application server uses
enum
24 matches
Mail list logo