[Noisebridge-discuss] Haschool

Jason Dusek jason.dusek at gmail.com
Sun May 10 05:10:10 UTC 2009


2009/05/09 d p chang:
> 2009/05/09 Jason Dusek <jason.dusek at gmail.com> writes:
>> 2009/05/09 d p chang:
>>> 2009/05/09 Jason Dusek <jason.dusek at gmail.com> writes:
>>>> Haskell invites us to consider computation from the
>>>> perspective of the typed lambda calculus.
>>>
>>> i've not thought at this level in a while, but isn't lambda
>>> calculus normally thought of as being normal order (pun
>>> intended :-) rather than haskell's lazy order?
>>
>> Well, normal order (outermost first) is actually quite
>> compatible with Haskell's lazy evaluation. When you evaluate
>> (at define time or at use time) is distinct from the order
>> you evaluate in (leftmost or rightmost).
>
> i was thinking about your first statement not expression
> evaluation order. i recalled (probably incorrectly and from an
> ancient version of the language) that the default was lazy
> (your 'use time' or 'call be need') and that one had to 'wrap'
> (in a monad) to get 'outermost first'.

  What does *when* they are evaluated have to do with the
  *order* in which they are evaluated? All Haskell values are
  evaluated outermost first (if they are evaluated at all).
  Specifically, they are evaluated to "Weak Head Normal Form";
  this is a good term to read about.

  To speak directly to your original point, lambda calculus is
  agnostic about reduction strategy -- one has a lot of choices
  on the matter. Call-by-need is closely related to normal
  order.

  What monads do is allow us to easily organize statements that
  we see as sequential (all nodes at certain level in the call
  tree) into a recursive structure (the first one contains the
  second which contains the third...). In consequence, they are
  evaluated in the order we expect. I recently wrote an
  illustrative email on just this topic.

>> To consider laziness in context with referential
>> transparency, evaluation strategies and sharing would make
>> for a long email.  This is certainly a direction we could
>> take in the course.
>
> that would be interesting, says my inner language theory nerd
> :-)

  It seems worthwhile to me, too -- let's make sure it's
  included.

--
Jason Dusek


 |...illustrative email...|
  http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/56723



More information about the Noisebridge-discuss mailing list