C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals Chapter 12 of 13

Play C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals Chapter 12 of 13
Sign in to queue


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 the
opposite 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!

Tune in. Learn and enjoy!

Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5

Chapter 6
Chapter 7
Chapter 8
Chapter 9
Chapter 10
Chapter 11
Chapter 12
Chapter 13





Right click to download this episode

More episodes in this series

Related episodes

The Discussion

  • User profile image

    So this wonderful series draws to a close on Christmas eve 2009, does that mean on Christmas day we get Haskell .NET? Wink

  • User profile image

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


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


    This lambda book looks nice to have as well.


    (End of lazy rewriting of post-)

  • User profile image

    It has been a great journey learning about functional programming in Haskell. To bad I’m going to be out of the country (no internet) for the last lecture Sad

  • User profile image

    I'll be out too for the last lecture. Hope I'll be able to watch it in China. Happy holidays and wishing great 2010 New Year!

  • User profile image

    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? Wink

  • User profile image

    I thought I understood lazy evaluation, but I didn't.  Very enlightening.  Thanks!

  • User profile image

    Charles and Erik,

    Does the series end on Xmas eve!?? What a strange coincidence indeed!

    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.

    Thanks again for these lectures!


  • User profile image

    Thanks so much everybody for the enthusiastic reception of the lecture series.


    I promised Charles to write a book on Rx and lecture about it on Channel 9. What I will probably do instead is lecture about it on Channel 9 and then write each chapter.

  • User profile image

    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.

  • User profile image

    I assume (end of year fire fighting and rush jobs, so no time to find out myself) that Rx is processed lazily, but would there be any scenerios where you would want to do strict calls?

  • User profile image

    While these lectures are coming to an end we can all look forward to the C9 letures on F#. Charles any idea when that's comming?

  • User profile image

    Soon.. Smiley

  • User profile image

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




    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 Smiley


    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.

  • User profile image

    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.

  • User profile image

    Interesting point, I'll have to think about that quite a bit.


    I'm not sure I fully get Monads yet.


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

  • User profile image
    Ryan Riley

    That will definitely be well-received! Thanks for presenting this fantastic series, Erik. Happy new year!

Add Your 2 Cents