comp.lang.functional Google Group

Re: future of lazy programming

dben...@eecs.wsu.edu (David B. Benson) — Thu, 07 Jul 2008 23:46:53 UT

Oh. I don't know. It strikes me as one of those 'common knowledge'
matters.
The other commenters here have pointed out the reasons that lazy loses
due to efficiency considerations, most of the time. Of course, there
will always be exceptions. So a good FP, IMO, is strict, mostly, but
allows for lazy via annotations of such.

Re: future of lazy programming

did...@lrde.epita.fr (Didier Verna) — Thu, 07 Jul 2008 08:25:52 UT

Err, about "lazy loses". I was wondering whether there were
publications about that.

Re: future of lazy programming

dben...@eecs.wsu.edu (David B. Benson) — Thu, 07 Jul 2008 02:22:12 UT

Sorry, pointers on what? Anyway, the subsequent comments have filled
out the issues rather well.

Re: future of lazy programming

j...@ffconsultancy.com (Jon Harrop) — Wed, 07 Jul 2008 02:47:48 UT

Whether or not Martin Odersky believes otherwise, the fact remains that
Haskell appears to be one of the world's most popular general-purpose
functional programming languages:
[link]
I have also heard that quote many times and it was attributed to Simon

Re: future of lazy programming

jhc0...@gmail.com (jhc0033@gmail.com) — Tue, 07 Jul 2008 17:25:31 UT

On Jul 1, 2:12 am, torb...@pc-003.diku.dk (Torben Ægidius Mogensen)
wrote:
I guess my question still stands. Why no per-file compiler flag to
default to strict evaluation in GHC?

Re: future of lazy programming

torb...@pc-003.diku.dk (Torben Ægidius Mogensen) — Tue, 07 Jul 2008 09:12:41 UT

You not only want perfect strictness analysis, you also want perfect
termination analysis. If an expression is guaranteed to terminate,
you will often want to evaluate it eagerly even if you are not sure it
will be used -- as long as the cost of evaluating it times the
probability for non-use is less than the overhead of laziness.

Re: future of lazy programming

vesa.karvo...@cs.helsinki.fi (Vesa Karvonen) — Mon, 06 Jun 2008 16:13:43 UT

[...]
The converse is also possible, given a language more expressive than basic
lambda calculus. For example, in a language with continuations, strict
evaluation can invoke a continuation that avoids going into an infinite
loop. Here are illustrative examples with SML/NJ and GHCi:
Standard ML of New Jersey v110.67 [built: Fri Jan 11 21:41:45 2008]

CfParticipation: ELW'08, July 7, Paphos, Cyprus

did...@lrde.epita.fr (Didier Verna) — Mon, 06 Jun 2008 14:56:14 UT

+----------------------------- ------------------------------ -+
| CALL FOR PARTICIPATION |
| 5th European Lisp Workshop |
| July 7, Paphos, Cyprus - co-located with ECOOP 2008 |
+----------------------------- ------------------------------ -+

Re: future of lazy programming

cdsm...@gmail.com (Chris Smith) — Mon, 06 Jun 2008 14:28:36 UT

Well, one answer is that it isn't just a matter of defaults. The
discussion up to this point has implied that choosing strict versus lazy
evaluation semantics is entirely symmetric. That's not the case. In
fact, lazy is correct, while strict is often more efficient, but
occasionally incorrect in that programs that produce a result in lazy

Re: The Importance of Terminology's Quality

l...@lewscanon.com (Lew) — Mon, 06 Jun 2008 11:51:21 UT

Re: future of lazy programming

did...@lrde.epita.fr (Didier Verna) — Mon, 06 Jun 2008 10:05:51 UT

I'd like pointers on this (scientific papers etc).
Thanks.

Re: The Importance of Terminology's Quality

Mon, 06 Jun 2008 07:07:03 UT

Why this response is so belated:
<[link]>
= <news:rem-2008jun25-003@yahoo.com>
Ah, thanks for the clarification. Is that info in the appropriate
WikiPedia page? If not, maybe you would edit it in?

Re: The Importance of Terminology's Quality

Mon, 06 Jun 2008 07:03:30 UT

Why this response is so belated:
<[link]>
= <news:rem-2008jun25-003@yahoo.com>
Please don't look at the orange and green checkered elephant
playing a harp off-key while sitting on a toilet and passing wind.

Re: The Importance of Terminology's Quality

Mon, 06 Jun 2008 06:44:02 UT

Why this response is so belated:
<[link]>
= <news:rem-2008jun25-003@yahoo.com>
Well at least you're three-quarters correct there.
But Lisp doesn't suck. That's where you're one quarter wrong.
I'm still waiting for you to precisely define what you mean by

Re: C'est fait pour Thuram

suomi...@innate.net (Teemu Suominen) — Sun, 06 Jun 2008 12:29:59 UT

Selkeä ja yksinkertainen kysymys päivän uutisannista:
______________________________ ___
A/ UFO räjähtänyt Vietnamissa. Kansa kokoilee miehen mittaisia mystisiä
paloja yhä. Jostain kumman syystä asiaa ei tutusti vaietttu? Ilmeisesti
syynä on se, että nykyään valtavasti ydinvoimalapäästöistämme ionisoituneet