[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