[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