[Noisebridge-discuss] Haschool

d p chang weasel at meer.net
Sun May 10 14:43:55 UTC 2009


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:
>>> 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'.
                        ^^^^^^^^^ 
crap, should have been 'innermost'

>   What does *when* they are evaluated have to do with the
>   *order* in which they are evaluated? 

hmmm... it doesn't. i thought i was trying to say that. the thinko i
mentioned above didn't help.

> All Haskell values are evaluated outermost first (if they are
                                                    ^^^^^^^^^^^
> evaluated at all).
  ^^^^^^^^^^^^^^^^

ahh... here's what i was screwing up. a look back at some ancient text
makes me think i am conflating normal form and normal order. sorry about
that.

yes, i realize i'm still not being precise here. non-lazy is
'applicative order' (reducing arguments to normal forms before the
function application) as opposed to 'normal order' (unreduced arguments
into functions before evaluation). what i've been calling non-lazy is
even 'bigger' than 'applicative order' in that i was thinking it
included 'strict-ness'.

>   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.

it is the 'expect' that made haskell 'special' to me (or maybe better
stated as: it is always a little jarring to try to switch my thinking
since i've grown to expect strictness, and i wasnt very good at swtching:-).

\p
---
The true worth of a man is to be measured by the objects he pursues.
		--- Marcus Aurelius



More information about the Noisebridge-discuss mailing list