Erik Meijer and Matthew Podwysocki - Perspectives on Functional Programming

Discussione

• 

  You talk alot about the Maybe monad, but you never mention the Nullable type in c# that I think is the same thing.  Both say there might be a value or there might not be.  The one thing I think c# does need is just to have a "pure" modifier  (like the static modifier), which doesnt allow any side-effects by not allowing access to the global and local store (just like the static modifier doesnt allow access to the local store of the object).  And then add a new type (like Action or Function) which would be a PureFunction, so that can you pass a pure function as an argument.

• 

  How are F# Asynchronous Workflows and Futures related? Could you implement asynchronous values with the same interface as futures/lazy values/promises?
  
  For example, assuming we have a promise library with these operations:
  

  1) p = new Promise() creates a new promise
  2) p.value <- val assigns val as the value of the promise
  3) p.value returns the value of the promise, or blocks the thread if nobody assigned a value yet
  

  Pseudo code:
  

  class Promise<T> {
      private T _value;
      private handle;
  
      public Promise() {
          handle = new ManualResetEvent(false)
      }
  
      public T value {
        get { handle.WaitOne(); return _value }
        set { _value = value; handle.Set() }
      }
  }
  

  You could implement a download function like this:
  

  download :: string -> Promise<Stream>
  download url =
      let p = new Promise()
      let req = HttpWebRequest.Create(url)
      req.BeginGetResponse(res => p.value <- res) // ommited boilerplate to extract the stream here
      p
  

  Use it like this:
  

  let page1 = download "foo.com"
  let page2 = download "bar.com"
  print page1.value
  print page2.value
  

  You can extract a pattern. If you have a value of type a, but the value is asynchronous (like a web page); it's really a function that you give a callback to:
  

  simple value: b
  async value: Async<b> = (b -> ()) -> ()  // (b -> ()) is the callback
  

  So it's a like a request in the above example: you don't have the actual web page, but you have a function that you can call (BeginGetResponse) and this function calls your callback when the web page arrives.
  
  We can extract the pattern of taking an async value and producing a promise out of it.
  

  async :: Async<b> -> Promise<b>
  async ayncval =
      let p = new Promise()
      asyncval (val => p.value <- val)
      p
  

  And implement download like this:
  

  download url = async HttpWebRequest.Create(url).BeginGetResponse
  

  Or if you don't support partial application:
  

  download url = async (callback => HttpWebRequest.Create(url).BeginGetResponse(callback))

  Why did the F# team go for asynchronous workflows instead of this approach?
  
  
  

• 

  cdwatkins: I also was thinking about the NULLable type in alternative for the Maybe monad, except that it doesn't contain the exception information for why it failed.
  
  Back to a more line of business view of things, Eric talks a lot about Haskell from the "everything functional" point of view, but where do you draw the line in the sand on what to use in the real ".Net" world; F# or Haskell? Especially as Haskell has the .Net libraries.
  
  I like what Matthew said about all a programmer really wants to do is a put/get and have the syntactic sugar handle the boiler plate coding for the processing of the exception. Even with Haskell (while I've not touched it since for some time) I haven't see how easy it is to process exceptions. It appears that it's designed for a perfect world that doesn't have exceptions. Is that really the case?
  

• 

  I hope Erik wears glasses during his lectures here on Channel 9. And he definitively needs a beard!!
  
  I loved this interview! Great stuff guys... keep on teaching.

• 

  dont forget the elbow-pached tweed jacket
  
  awsome stuff! what i really like about erik is the uncondecending tone of all his interviews, its only about relaying understanding looking forward to more of those conceptual talks

• 

  Regarding Haskell and exceptions, may I suggest Real World Haskell chapter 19? You might also want to read Simon Marlow's paper on extensible exceptions, the latter being realized in GHC 6.10.1.

• 

  Thanks for that viellevigne, it was very interesting. It leads me to think why we could not have inline Haskell or F#?
  
  Real World Haskell
  

• 

  Thanks!  I had a lot of fun doing this talk.  I hope we captured a bit of what I like to talk about on my blog and during my talks at various conferences.  Hopefully I'll be around here again!
  

• 

  Well, there are two ways about handling failures.  There is the use of the Maybe Monad which states that you have Just the value or Nothing at all.  But sometimes, we want to be a bit more explicit than that.  For example, we may want an error message, or in the case of F#, the actual exception itself, or the return value from the function.  If you use the Async.Catch function from the F# Async Workflows, it is exactly that which either returns the computed value or the exception should one occur.
  

• 

  In a way the Maybe is like the Nullable type, but it's a bit more than that since it's a unifying type which says what has a value and what does not for both reference types and value types. 
  
  Your thoughts around pure actions and purity is interesting, but since C# is a first class object oriented language with many imperative features, it's hard to bolt on such concepts as immutability (deep and/or shallow), purity, side effect free functions and so forth.  With the utilization of Code Contracts for .NET 4.0, we could get part of the way there, but for the most part, any checks for purity are mostly just suggestions and not enforced.  Instead, concepts such as these belong in its own language, for which F# is well suited on the .NET platform.  Although there are projects to bring Haskell to interoperate with .NET hs-dotnet.
  

• 

  The approaches are similar and both the Task Parallel Library and Async Workflows were originally developed mostly independently and for different reasons and have different audiences.   There are certain things that TPL cannot do that F# async workflows can such as multiple downloads without any blocking threads.  Promises block at the .Value property call.
  
  As for unifying TPL and Async Workflows remain to be seen and it may happen.  I can't speak for the F# team on this one although we do like to talk often enough.
  

• 

  Given that reference variables can already be null or else point to something useful, don't they already have what is needed to represent the maybe monad? All that's lacking is the convenience of bind. An extension method can act as the bind operation and that's all you need, isn't it? Or have I missed something (I'm relatively new to Haskell!)
  

• 

  There is a very important difference, and it's that reference types don't prevent you from calling a method on something that's null. 

  In haskell, if you try to pass a Maybe String to a function that accepts a String, you'll get a type error. In C# every reference typ can be null, which means that a function that takes a string may have to make do with a null instead. There's no way of saying that you do not want to accept a null reference to a method (and get static checking for that) because there is no notion of "non-nullable references" in C#.

  
  

  It seems that a lot of people, including Tony Hoare who invented null pointers and members of the C# design team IIRC, now agree that "nullable by default" was a mistake, and that regular  references should not be allowed to take a null value, instead you'd have to explicitly annotate a type with a ? (or something) to indicate that this reference may be null (and there would be some syntactic construct for "unpacking" a T? into two branches, one which gets passed a T and one which has to deal with what to do if the T? was null). 

  To bad that changing this would probably be way to cumbersome considering existing code (e.g. the entire framework!), but there's definitely value in being able to eliminate (statically) any chance of null pointer exceptions by just splitting the two concepts "reference" and "nullable" into two parts rather than conflating them into a single concept.

• 

  Yes, I saw that Hoare quote. That's the same conclusion I get to in that blog post, i.e. "It's not immediately obvious that it is [a bind function], because a Bind function talks to its caller in terms of values wrapped in the monad, but deals in "naked" values with the function passed to it. But IfNotNull uses ordinary reference variables in both situations. This is because there is a feature missing from C#. It ought to be possible to somehow tag a reference variable to say that it is definitely not null."
  
  In Spec# they used MyRefType! (exclamation suffix) to mean non-nullable; so the default is wrong but they were aiming at backward compatibility with C#, so they had to go that way. And then they would just look for an if (myVar != null) and silently make myVar non-nullable within the truth block.
  
  It looks like the closest we'll get to this in real C# is the Code Contracts library in CLR 4.0, but I really wish non-nullable was the default. Unfortunately it complicates the syntax in some areas (where should non-nullable instance fields in a class be initialized?) but it would surely have been worth it, as Hoare says.
  

• 

  I ran out and got a copy of Intro to Functional Programming after watching this. I can't wait to see Erik's lectures. Always interesting!
  

• 

  I love the way Erik says "Func" at about 10 minutes into the video. It reminds me of the classic "Rock Me Amadeus" by Falco!

• 

  Excellent. I've been reading my copy too. You'll see the first in the lecture series soon. Waiting for some white boards to arrive for use in the studio. The format for this will be different than my usual style. I plan on shooting these in our studio.
  
  C

• 

  Hello guys
  
  this video on Perspectives on Functional Programming aside from being as totaly interesting as with all the other related videos had the nice thing of showing some recommended books to get more information on where to do more research on your own was fabulous.
  
  I think it would be nice to add some way of letting c9 users to contribute on each videos pointing to other sources where to find information, like some webcasts, videos, articles, books (in the same post screen) so people can have a quicker access to other recommended material and shorten the time spent in searching for the correct information on the internet.
  
  Great work your doing, i find it fantastic
  
  best regards
  hec

• 

  Thank you Erik Meijer and Matthew Podwysocki!  =).  I just began looking into F# (and even more recently, haskell) and felt like I wasn't understanding monads.  While Brian Beckman's "Don't fear the Monads" gave me a great introduction to understand monads, your example completed the understanding for me.
  
  The best part of the video, in my opinion, was how you revealed that C++ is like a giant state machine.  I never thought of this, and this idea you presented made monads finally "click."  As C++ is basically one giant state, in which it is assumed that each operation produces side effects, finally got it to fit in.  My problem was that since I came from a mostly imperative background, I really didn't understand what pure really meant.  If you were to ignore the current technological limitations such as division by zero, explaining what the tail of an empty list would be, etc, then there would never be a single issue arising from any operation in a pure haskell function!
  
  Thanks again for the info, and especially for the maybe monad and C++ ideas.  You guys explained it perfectly  =D
  

• 

  It's always very interesting to see a video with Erik Meijer. Such a lively talking man!

• 

  I am into moving into functional programming (Haskell, F#) for the last few months. I have read Expert F#, Real World Haskell etc.

  I am liking the ideas and styles and started coding some fun stuff with great things there in F#.

  I was disappointed by the quality (succinctness and clarity) of this video compared to other numerous videos which I have seen from c9 or msdn. (Maybee worst of all which I have seen) Sorry, Matthew and Eric, but I missed the flow and stopped watching the video in the middle.

  I am sorry if I am rude but I got one point from this lecture that intellisence is some kind of bad thing. The examples could have been given either in pseudo code (without any reference to syntax) or with correct syntax of either F# or Haskell.

• 

  does anyone know where i can find "Introduction to functional programming" book? amazon.com don't have.

  Is this the correct ISBN #? 0134841891

   

  cheers,

  amir