Description

In Chapter 12, Lazy Evaluation, Dr. Meijer takes us on a journey into the world of order of evaluation (when expressions are evaluated). In the case of lazy evaluation, computation is delayed until the result of the computation is known to be required.

Most programming languages that most of you use day to day use eager or strict evaluation, which is theopposite of lazy evaluation. In the strict evaluation world, expressions are evaluated as soon as they are bound to a variable (this is also known as greedy evaluation). In Haskell, laziness is first class!

The Discussion

$! - Talk about bang for the buck ("show me the money"), just in time for christmas

It's nice to know when to introduce strictness. As for how lazy evaluation deals with this accumulation, isn't that a matter of choice on part of the compiler writer? I would assume that is what "strictness analysis" is for. Looking closer...

I hope the lectures continue from time to time after this one is done. It would be cool with an audience (local or otherwise) of a select few (one or more) that can ask the right questions at the end, having witnessed the lecture, just to make the experience
more interactive. But this has been a truly great initiative. In a typical Channel 9 video you learn something but here the amount of knowledge density is greater (sans the interactive Meijer-Beckman combo which also has great knowledge density, sometimes
too great heh.)

By the way Erik, have we caught you doing destructive updates of the whiteboard?

Absolutely fantastic series; all developers should make an effort to understand functional programming in general and haskell in particular. I think it broadens your horizons and makes you a better professional.

You're writing a book on Rx Erik? Awesome. I'll take my place in the long queue of folks offering to act as technical reviewers - although I suspect you won't be short of 'in house' offers. Over the past 18 months, in large part because of the conversations
and lectures from yourself and Brian I've found that "composition" has become my new programming mantra. Hope you have a great holiday and a brilliant 2010.

Well I have to be careful as I've had a lot of brandy tonight.. it is christmas after all, and I am Irish!

But

Lazy Evaluation is a specific name for a more general concept; and in my opinion that more general concept is Delegation. In many ways we ultimately try to model computations on how we process things ourselves: abstractly our brain processes information streams,
and reacts to what we receive: event based programming over streams... thanks for Rx

But delegation is key to ANY model of higher order-ness, because we delegate the evalution of a "value" to the "item" than can more functionally evaluate that in the best fashion.

Personally I'm an architect, and I consider deployinging a solution as an aggregate of tenchology and people. However you always have to delegate to people, and if you unfold the implementation of a project what you realise is that people are the most important
function that are applied to data.

I'd say that applies more to the notion of monads, where you are explicitly distinguish between values of type T and computations of type M<T> (which of course themselves are first class values). In your words, you are delegating the computation of a value
to the monad.

How does this relate to the concept of an object type? A package of state and behaviour ... is a Monad just an object that obeys a certain behaviour pattern? I've seen them described as amplified Types, and clearly if you have your type obey the behaviour
pattern (the monad laws) you get compositional types. I don't quite see yet how this differs from an Type that implements an interface with Bind and Return/Unit methods and thus are supported by certain syntax. Suddenly everything starts to look like a Monad
of some sort if it encapsulates data and computations.

I think I'm missing some key insight that differentiates a Monad from an object type: they look very similar to me, both of them represent state and behaviour that can be applied to that state - is it just that a Monad has something more specific to say
about the behaviours that are applied? I'm guessing this is what gives them the mathematical properties that allows you to reason about them in a certain way...