🚀 go-pugleaf

In article <4682@osc.COM> jgk@osc.COM (Joe Keane) writes:

   In article <ACHA.91Mar21112142@DRAVIDO.CS.CMU.EDU> acha@CS.CMU.EDU (Anurag
   Acharya) writes:
   >I am curious about the kind of applications that lazy functional languages
   >are suitable for. What can you do with such languages (in a natural and
   >elegant fashion) that you cannot similarly do with a strict language augmented
   >by a lazy type constructor ?

   Nothing.  Besides the obvious argument of Turing equivalence, 

this isn't at all what the question was.

   given any language i can think of you can show how to implement
   lazy closures.  In C you can use structs and function pointers.

you can store-away a function that already existed at compile time,
but you can't create new functions (unless you count forking off cc
and dynamic loading :).  Please show us how, if you think it can be
done.

  In Scheme you can implement `delay'
   and `force' as lambda expressions.

Not really.  They have to be special forms.  Or macros.  In either
case, they are not functions.

   For example, the C operator `&&' is defined to be lazy in its
   second argument.

   << more of the same, ie non-strict = lazy >>

strict/non-strict is a different issue, although they are related.  At
best, I think you are stretching the definition of lazy much too far.
non-strict can be implemented with lazy, but lazy implies far more
than non-strict.

   In terms of correctness, making a strict function lazy never hurts.

not true, side effects.

   So it makes a lot of sense to have a language where every function
   is lazy. 

he he

   This eliminates an artificial distinction, and allows you
   to get the benefits of laziness everywhere, not just where someone
   thought it might be useful.  So why don't people do this?  The
   answer is always the same: ``It's too slow.'' 

damn right

   Some people claim this is an inherent problem with lazy languages.
   I strongly disagree with this position.  Naive implementations do a
   lot of unnecessary testing and jumping around, and i'm afraid that
   this has given lazy languages a bad reputation for inefficiency.

laziness has significant cost.  laziness is occasionally useful.  It
only really pays off when you don't evaluate an argument.  but this
doesn't happen very often.  So you rarely benefit from it.  But you
always pay for it.  It's fine in an interpreter.  It's a big lose in a
compiler.

not to mention that it plays hell with side effects.

   With the proper techniques, a lazy language can be faster than a
   traditional one. So for now, i'll just leave this as an
   unsubstantiated claim. 

no kidding

--

			christianity is stupid
Scott Draves		communism is good
spot@cs.cmu.edu		give up