Can't help but comment...

"Purely functional languages like Haskell are excellent within certain niches, but non-trivial problems exist with language interoperability between lazy and strict languages."

I don't wish to appear to be too harsh on Microsoft, (after all they are supporting work on GHC) - but they tend to ignore all non-Microsoft solutions... deliberatly (its a marketing thing). So when you read the above - you have to substitute "Microsoft languages" for "strict languages" for it to really make sense ... after all C is the predominant language of the day, and I have found it relatively easy to do C FFI stuff, okay so you have to allocate and deallocate memory, but you would have to do that in C anyway. It seems to me the author of that quota had "languages" like Visual-Basic in mind. Here the work of marshalling is pretty complex compared to usual Visual-Basic fare... The other area (again MS specific) that F# has better interoperability, is .NET . F# (notice similarity to C#) is a funtional language within the .NET framework - hence supports the 'COM' style interface within the language primitives, just like C# does. This means coding a .NET component in F# is trivial - In haskell its still pretty hard-core (its hard even in C hence the prevelence of visual-toolkits on the MS platform - and also the eventual development of C#) The only way the author of this comment can be persuaded to delete it I think is if Haskell were to have a neat .NET component interface, unfortunately Haskell's class system is not up to incorporating OO hierachies like .NET without some changes... I think however the complexities mentioned relate to .NET / COM style object systems, and not traditional languages like C. Maybe we should ask for the quote to be revised to: "interoperability between lazy and component based object hierachies" ? Keean.