Slashdot Mirror
Functional Languages Under .NET/CLR
Numen writes "With all the talk of .NET being thrown about there is a common factor occuring through many discussions, namely the claim that .NET will be unable to address functional and logic languages such as Prolog and LISP.
To this end I would like to drawn peoples' attention to two resources, that shown how this may well be a non-issue, and to ask, does this change anybodies mind?
"
After reading Miguel's long response to the Register article, I've really changed my mind about .NET architecture. I think I'm going to get a book and start learning it, maybe try to contribute to his effort.
Moderation: Put your hand inside the puppet head!
Another good example, as covered in Dr. Dobbs last issue, is Mondrian. You can read a paper about it here(it's a PDF). You can download the compiler and view documentation at the mondria-script web-site.
.NET Framework.
Here's a blurb from Dr. Dobbs:
Mondrian is a modern, purely functional language specifically designed to leverage the possibilities of the
/* CDM */
Does anyone know how .NET does for speed?
.NET introduce an even bigger overhead, or have they sorted it out?
.NET instead? Will the tailor-made version be more efficient because it's designed with the language in mind, or does the benefit of having all the optimisations done on a common system compensate for that?
ie, Java takes an absolute age to initialise which makes it unsuitable for desktop applications or utilities (although people still try... maybe in a few years' time...).
Does
Also, is there any overhead for languages that aleady use a VM (eg, python, perl) if they switch to
I really like the idea of a common cross-platform runtime, but not if it makes my text editor take 5 seconds to load!
For example, scheme is hard to compile towards the JVM or standard C because both lack proper tail call implementation (poping the parameters in the stack before calling a function in tail position).
You can of course circumvent this because as you say the target language is Turing complete, but you lose a lot on performance if the target isn't tailored to this particular use.
Relinquish
all four Prolog and LISP Win32 applications developers were getting nervous.
nice solution to a non-issue.
The problem lies in the CLS: Common Language Specification. .NET libraries and applications can be written in a colorful mix of languages and must be able to interoperate. Interfaces tend to look a little bit differently in functional languages than in imperative ones. If I use feature X of my preferred language in my library, which isn't available in your preferred language, you won't be able to use the library how it's supposed to be used. Herein lies the difficulty: making those inter-language operations as painless as possible. It's a hard problem and while going to a lowest common denominator is surely a possibility, it surely will alienate the users of say functional languages.
-- The plural of 'anecdote' is not 'data'.
The SML.NET compiler hasn't yet been released by Microsoft Research but hopefully it will be soon. As I understand it, it is a complete implementation of Standard ML, with a few (small) extensions to hook into the .NET object model.
In my opinion, this could be one of the best opportunities functional programming has to gain mainstream acceptance, because of the ease with which it will be possible to link functional code with imperative code.
Let me ask you all a question: If any language that you currently use is compiled into native machine code (for x86, or PPC, etc.), then why wouldn't .NET or the JVM support it?
You have to remember that both IL and JBC (Java Byte Code) are essentially virtual CPUs that have some high-level features tacked on to simplify implementing certain kinds of langauges. However, they are still just basic assembly like langauges. Anything one could do in native assembler, one could do in IL or JBC. In fact, not trying to support one or the other, IL is probably a slightly better candidate here because Microsoft uses it to compile to native x86 assembler. Hence, there is support for direct memory manipulate (something the JBC doesn't have).
So, can someone implement Lisp using IL? Why not? They did it with C or assembler before. Can someone implement Smalltalk? David Simmons already has at http://www.smallscript.com.
I applaud Miguel for trying to bridge the gap between the Windows and *nix world in innovative ways. Good luck!
A lot of the debate about .NET and the open source focuses on the technology, and not the strategy.
.NET? Well, .NET is a technology, but it is also a strategy. Its aim is to completely dominate software development in the future.
.NET to be successful, they need to win developers over to it. In order to do that, they need to give the appearence of it being an open and non-threatening platform to use. But that's only appearances. Their aim with .NET is to completely dominate the provision of any type of software service over the internet (which will include pretty much everything within a decade) and to get their slice of every transaction made.
.NET. If you think you will ever beat Microsoft by playing by their rules then you have your head in the sand. Think about what contingency plans Microsoft might have in place. Remember that they have a war mentality - what would you do if you were Microsoft? Think about the Haloween memos.
.NET strategy still vague, when Microsoft is "betting the barn" on it?
Let's consider some facts first. One of Microsoft's basic strategies is the complete domination of markets. They make no secret of this (although they have not been successful at it outside of the desktop space). Here are some instances where senior Microsoft people have stated they want to completely dominate a market:
1) Internet access with MSN.
2) The handheld market with Windows CE
3) The game console market with X-Box.
In all three cases above, they have made it clear that they intend to dominate that market, and have even stated that it is "the Microsoft way" to do so. They're not interested in 50%, they want 100. Admittedly they haven't yet been successful in this any of the above markets (in fact I think we can now safely say that they've failed with Internet access), but that is their intent.
So, what has this to do with
Now, Microsoft's strategists will have spent a long time thinking about this. They will have hypothosized about potential problems, and developed contingency plans. Microsoft knows that in order for
That's why I despair when I hear people in the Open Source community talk about implenting stuff in
Has anyone, for instance, looked through all Microsoft's patents, to check that their isn't a surprise that they could pull out of the sack if things aren't going their way? Has the Gnome Foundation, for instance, got the financial means to defend itself should Microsoft attack it legally? Why are some parts of the
.NET is perhaps great technology. But I implore everyone in the OSS community to stay away from it. Bill Gates will tell you that the best technology doesn't necessarily win in the long term, it is what has mindshare. OSS is getting more mindshare every day. Don't help MS by supporting their technologies. Your software project will get killed if it starts to threaten MS if you do.
.NET is just another one of Microsoft's over-engineered solutions. It looks simple on the outside, but when you get down to it the complexity is overwhelming. It's really sad to see so many open source developers being lulled by Microsoft's latest technological tactic.
.NET well!
Who out there remembers DDE, OLE, MAPI or DocObjects? How about MFC (.NET 0.5...)? If you do, remember how well (not very!) these "technologies" worked outside of the boxes Microsoft created them for? Has anyone out there actually tried to work with, for example, Exchange server?
Microsoft fears clonability, and to prevent it they create complex APIs with lots of hidden underspecifications. Then they get developers on board by creating pretty, easy-to-use tools and hosting big developer conferences. And they make it feel cool through shrewd marketing. But at the end of the day, you find that you've spent 90% of your time trying to work around some deficiency. And it's not because Microsoft was especially dumb when implementing this stuff, its just that the stuff is needlessly complex to begin with!
We're doing fine as we are. Don't drink from the
Why? One major advantage of functional programming languages for optimization is that the compiler knows that almost nothing can change behind its back: variables can't get updated, data structures can't get changed, etc. With VLIW architectures like Itanium and hyperthreading, functional programming languages can potentially do much better relative to traditional languages than on older processors. But in order to so so, their compilers need a degree of control over code generation that simply isn't available if you go through CLR or JVM.
Furthermore, the entire runtime of a functional language is optimized for the kinds of allocation patterns that come along with functional programming, while CLR and JVM are optimized for OOP. For lazy functional languages, there are some additional issues when it comes to expressing lazy evaluation efficiently.
Altogether, though, I think it really doesn't matter. CLR and JVM are good and fairly flexible platforms, but platform evolution won't stop here. If anything, Sun is a bit more honest in this regard, making no bones about the fact that JVM is primarily a Java platform, even though there are dozens of other language frontends available for it; CLR claims universality, but really isn't any better than JVM.
If you don't care that much about performance, you can use your functional language under CLR and JVM. If you want a high-performance functional programming language, you can use one of the dedicated native code compilers and runtimes that will continue to be available. CLR and JVM will not end the evolution of other runtimes.
To take one example, in Lisp you can pass nameless functions quite easily. So you might have a library that has a function to create a new button. One of the arguments to the function is a function that the library will execute when the button is pressed. In Lisp this is a trivial thing, you just create a function and pass it as the argument. But if nameless functions are not supported by the virtual machine, then this operation becomes very problematic.
What if the nameless function is created dynamically by the program? How can the virtual machine compile this nameless function to native code before running the program? Unless the virtual machine knows how to compile Lisp code, it cannot. It may be that the Lisp library must be changed to accept some other form of argument for the callback for efficiency reasons. If most of the work you do is just calling libraries and putting things together, you just lost one of the biggest features of Lisp. You have to trade off efficiency and convenience. If you use a native Lisp virtual machine, you have both efficiency and convenience.
I took a look around and found this link to a guy called Don Syme at Microsoft Research who appears to be working on just this.
There's also the Mondrian project, which implements Haskell.
I'm actually excited about the .NET framework (well, the CLR) because it will mean I can use my favorite functional language, SML, to write Windows apps.
It's also from MSR: http://research.microsoft.com/Projects/SML.NET/
Why do we care? In a really old thread I rant about the virtues of modern functional languages (and indirectly, SML). I think it's still relevant, though most of the other languages associated with .NET (ie, C#) have some of the same basic benefits now (like safety and portability). Here:
http://slashdot.org/comments.pl?sid=6343&threshold =1&commentsort=0&mode=thread&cid=929697
If you want to learn SML, or learn why I think it is so cool, maybe you'd like my under-construction tutorial called SML for Hackers: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tom 7misc/docs/sml/ml-for-hackers.txt?rev=1.3&content- type=text/vnd.viewcvs-markup
Part of Java's slowness in initializing is that it does extensive security oriented bytecode verification of every class loaded. If .NET doesn't do that, it will be faster, but arguably not as secure against people rearranging the CLR bytecodes in ways that a compiler conforming to the security spec wouldn't. BTW: You can disable this as a command line option to your JVM and speed things up if you trust your .class files, but the default is to be secure.
As long as the language is Turing-complete, it should be possible; the question is in the level of difficulty, and I don't see why .NET would be harder to support than, say, TCP/IP or HTTP. I mean, Emacs was written in LISP; if they can do that, is .NET such a challenge?
There is a big difference between implement EMACS or TCP/IP *in* a language and implementing a language *on* .NET! Your mixing apples and oranges.
Nevertheless, there is no question whether functional and logic languages can work on .NET. The only question is whether they can work with sufficient efficiency that they will be tools, not toys.
I think that this is an instance of an unclear question. The question is not "Is it possible to implement functional languages in .Net?", but rather, "Do the bytecode primitives efficiently support execution of functional language primitives?"
You might be able to implement a functional language interpreter supporting closures, lazy evaluation, etc., in the standard bytecode, but that's not the point. The point of the CLI is to effectively support efficient execution of programs written in ANY language. Therefore, writing another layer on top of the bytecode to support features unique to functional languages eliminates many advantages functional languages provide, and can potentially disallow correct execution of complex functional programs.
So, if the bytecode representation was designed to support object-oriented languages, it's probable that it WILL NOT efficiently support recursion and partial evaluation. This is the crux of the argument, and why people are concerned with the existing bytecode spec.
There is a lot of work being done in this area, though, so there is hope that this will be resolved. After all, Microsoft does have some of the best minds in functional programming thinking about the problem.
For more information, see:
http://research.microsoft.com/~dsyme
http://www.research.microsoft.com/~emeijer
http://www.mondrian-script.org
- j
You know its intersted that Java wasn't designed for having lots of short-lived objects. Think of the performance benefits programmers might see (like in for loops, using String instead of StringBuffer etc).
Purely functional langauges stateless work quite well under an object oriented frame work. Yes, I know objectes are supposed to have state. Object level states are handled very well in all modern purely functional langauges via monads. I think Haskell has transioned to COM programming very nicely.
.NET. They are not even adding support for the various open source technologies like CORBA. I expect that you will find open source operating systems to be a bit behind the times langauge wize in a few years.
As a side note, anyone notice how all the current langague research is going on under Windows with Microsoft grants? Currently, most of the projects simultaniously support Windows and Linux, but these projects are currently focusing a lot of attention of COM and
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
Look at it this way: if .NET is all MS says it will be then they will be opening themselves up to more and more competition; they will be creating a freer market for code than exists today. Surely no one here is so stupid as to imagine that's what MS wants?
.NET will launch with as much support as the marketing department can get for it and then it will slowly morph.
Each year will see a new version with more API calls etc defined and, you know what? Just after that all the MS programs that have been written using the beta versions of those API's will come out, well in advance of even the poor dupes that fork out for MSDN.
Everyone apart from MS will be playing catch-up again.
How many fucking times do you have to be done over before you learn???
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Okay, I apoligize for an extra long post here, but I still see people mischaracterizing functional programming. So I'm going to take a few excerpts from "Why Functional Programming Matters" by John Hughes. It's a short paper, worth your time if you're new to the functional paradigm.
No Side Effects:
Functional programs contain no side-effects at all. A function call can have no effect other than to compute its result. This eliminates a major source of bugs, and also makes the order of execution irrelevant - since no side-effect can change the value of an expression, it can be evaluated at any time. This relieves the programmer of the burden of prescribing the flow of control. Since expressions can be evaluated at any time, one can freely replace variables by their values and vice versa - that is, programs are "referentially transparent". This freedom helps make functional programs more tractable mathematically than their conventional counterparts.
Higher Order Functions:
Functional languages allow functions which are indivisible in conventional programming languages to be expressed as a combi-nation of parts - a general higher order function and some particular specialising functions. Once defined, such higher order functions allow many operations to be programmed very easily. Whenever a new datatype is defined higher order functions should be written for processing it. This makes manipulating the datatype easy, and also localises knowledge about the details of its represen-tation. The best analogy with conventional programming is with extensible languages - it is as though the programming language can be extended with new control structures whenever desired.
Lazy Evaluation:
A complete functional program is just a function from its input to its output. If f and g are such programs, then (g . f ) is a program which, when applied to its input, computes g (f input). The program f computes its output which is used as the input to program g. This might be implemented conventionally by storing the output from f in a temporary file. The problem with this is that the temporary file might occupy so much memory that it is impractical to glue the programs together in this way. Functional languages provide a solution to this problem. The two programs f and g are run together in strict synchronisation. F is only started once g tries to read some input, and only runs for long enough to deliver the output g is trying to read. Then f is suspended and g is run until it tries to read another input. As an added bonus, if g terminates without reading all of f 's output then f is aborted. F can even be a non-terminating program, producing an infinite amount of output, since it will be terminated forcibly as soon as g is finished. This allows termination conditions to be separated from loop bodies - a powerful modularisation. Since this method of evaluation runs f as little as possible, it is called "lazy evaluation". It makes it practical to modularise a program as a generator which constructs a large number of possible answers, and a selector which chooses the appropriate one. While some other systems allow programs to be run together in this manner, only functional languages use lazy evaluation uniformly for every function call, allowing any part of a program to be modularised in this way. Lazy evaluation is perhaps the most powerful tool for modularisation in the functional programmer's repertoire.
Why you might care:
Modularity is the key to successful programming. Languages which aim to improve productivity must support modular programming well. But new scope rules and mechanisms for separate compilation are not enough - modularity means more than modules. Our ability to decompose a problem into parts depends directly on our ability to glue solutions together. To assist modular programming, a language must provide good glue. Functional programming languages provide two new kinds of glue - higher-order functions and lazy evaluation. Using these glues one can modularise programs in new and exciting ways... Smaller and more general modules can be re-used more widely, easing subsequent programming. This explains why functional programs are so much smaller and easier to write than conventional ones. It also provides a target for functional programmers to aim at. If any part of a program is messy or complicated, the programmer should attempt to modularise it and to generalise the parts. He should expect to use higher-order functions and lazy evaluation as his tools for doing this.
Functional programming language are an excellent match to the needs of modern processors. In fact, the only reason C and Fortran aren't complete dogs is because we invest enormous amounts of effort in adding special-purpose processor features to support imperative constructs, including speculative execution, branch prediction, byte-wise updates, instruction-level parallelism, etc. None of that hardware does any good for the computation itself--it just eats up precious real-estate in order to support the semantics of languages like C and Fortran. Functional programming languages not only remove the need for most of that hardware, they are also nicer to program in.