On Jul 8, 2005, at 10:20 AM, Jean-Philippe Bernardy wrote (in an
exchange with Colin Runciman):
My interaction depends on the (subtle order of) evaluation of a
pure and
total function?
Pure, yes; total, no.
Many important things depend on order of evaluation in lazy programs:
for example,
It seems to me that this sort of thing is why haskell is difficult to
compile to efficient code. I have the impression that relaxed
semantics wouldn't hurt 99% of programs while make the compiler-writer
job easier. The only disadvantage is that tricks like the above one
wouldn't work any more.
An
> >>My interaction depends on the (subtle order of) evaluation of a pure and
> >>total function?
> >>
> Pure, yes; total, no.
>
> Many important things depend on order of evaluation in lazy programs:
> for example, whether they compute a well-defined value at all! The
> interleaving of demand in
On 7 Oct 2004, at 22:14, Amadeo Casas Cuadrado wrote:
Hello,
Could anyone tell me where can i find a webpage or a paper about how
lazy
implementation is done is Haskell?
For much more than you could ever want to know about haskell, look in
Simon Peyton Jones's page:
http://research.microsoft.co
Hello,
Could anyone tell me where can i find a webpage or a paper about how lazy
implementation is done is Haskell?
Thanks a lot!
--Ama
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
> I wonder if I could run an idea I've had by this list. It seems to
> me you could get some of the desired effects of lazy evaluation by using
> continuation passing style in code. For example, take this psuedo-code
> using CPS to represent an infinite data type.
This has
On Fri, Jan 24, 2003 at 09:18:47AM -0600, Kevin S. Millikin wrote:
> > "Chris" == Chris Clearwater <[EMAIL PROTECTED]> writes:
>
> Chris> LIAR. You want to steal my idea for yourself! It's MINE! :)
>
> I hate to be the one to break it to you, but we used to routinely show
> this trick to
On Fri, 24 Jan 2003 09:18:47 -0600
"Kevin S. Millikin" <[EMAIL PROTECTED]> wrote:
>
> So your trick *is* used to implement lazy evaluation in other
> languages. It's not very pleasant if you write a lot of lazy code,
> because you have to explicitly s
ons-stream, etc.), or
just the lambda-ification, as proposed by Kevin Millikin. It is
not even clear *to what* you should apply your continuation.
However, Kevin S Millikin is too pessimistic about
So your trick *is* used to implement lazy evaluation in other
languages. It's not very pleasant
#
> (ones)
(1 . #)
> (cdr (ones))
#
> ((cdr (ones)))
(1 . #)
Of course, if we wanted *lazy* evaluation, we would want to avoid
performing the cons more than once if it is demanded more than once.
We have to use something other than lambda for that:
> (define ones (delay (begin (printf
> "Chris" == Chris Clearwater <[EMAIL PROTECTED]> writes:
Chris> But also, this brings me to another idea! Data structures
Chris> should be built from lambdas and CPS! For example, a list
Chris> of integers: 1 : 2 : 3
Chris> list = \c -> c 1 (\c -> c 2 nil)
How about just:
On Fri, Jan 24, 2003 at 03:07:48PM +0100, Thomas Johnsson wrote:
>
> >
> > Yes I am. But the + should be in CPS form anyways to be perfectly
> > correct, so: natural n c = (+) n 1 (\m -> c n : (natural m))
> >
>
> I think Jerzy (in his usual polite manner :-) refers to the
every group has
On Fri, Jan 24, 2003 at 01:51:57PM +0100, Jerzy Karczmarczuk wrote:
> Chris Clearwater wrote:
> >It seems to
> >me you could get some of the desired effects of lazy evaluation by using
> >continuation passing style in code. For example, take this psuedo-code
> >using C
fre 2003-01-24 klockan 13.21 skrev Chris Clearwater:
> I wonder if I could run an idea I've had by this list. It seems to
> me you could get some of the desired effects of lazy evaluation by using
> continuation passing style in code. For example, take this psuedo-code
> using
I wonder if I could run an idea I've had by this list. It seems to
me you could get some of the desired effects of lazy evaluation by using
continuation passing style in code. For example, take this psuedo-code
using CPS to represent an infinite data type.
Using non-CPS this wou
Chris Clearwater wrote:
It seems to
me you could get some of the desired effects of lazy evaluation by using
continuation passing style in code. For example, take this psuedo-code
using CPS to represent an infinite data type.
Using non-CPS this would be something like:
ones = 1 : ones
using
I wonder if I could run an idea I've had by this list. It seems to
me you could get some of the desired effects of lazy evaluation by using
continuation passing style in code. For example, take this psuedo-code
using CPS to represent an infinite data type.
Using non-CPS this wou
On Thu, 11 Apr 2002, Jay Cox wrote:
> I still am trying to write a document about strictness and haskell
> evaluation for those of us without research degrees ;-)
Just to say something quick. There are a few of you that actually
responded when I was going to write what I then called "A strictne
On Mon, 4 Mar 2002, Tom Pledger wrote:
> Nguyen Phan Dung writes:
> :
> | mylist :: [Integer]
> | mylist = [1..10]
> |
> | In Hugs, I type mylist to print out all the elements inside. However,
> | after printing about 22000 elements, the system crashs & outputs:
> | "Garbage collec
Nguyen Phan Dung writes:
:
| mylist :: [Integer]
| mylist = [1..10]
|
| In Hugs, I type mylist to print out all the elements inside. However,
| after printing about 22000 elements, the system crashs & outputs:
| "Garbage collection fails to reclaim sufficient memory"
The declarati
Hello,
Sorry for asking such
a silly question: Haskell is using lazy evaluation. So, it means we should be
able to declare and use a list of billions elements without any trouble. So I declare
my list as follow:
mylist :: [Integer]
mylist =
[1..10]
In Hugs, I type
21 matches
Mail list logo
