F#

[MR K P SCHUPKE]

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.