Slashdot Mirror

← Back to Stories (view on slashdot.org)

Functional Languages Under .NET/CLR

Posted by Hemos on from the fuel-for-the-fire dept.

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

2 of 344 comments (clear)

  1. What about speed? by tal197 · · Score: 5, Interesting

    Does anyone know how .NET does for speed?
    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 .NET introduce an even bigger overhead, or have they sorted it out?

    Also, is there any overhead for languages that aleady use a VM (eg, python, perl) if they switch to .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?

    I really like the idea of a common cross-platform runtime, but not if it makes my text editor take 5 seconds to load!

  2. Why Functional Programming Matters by dstone · · Score: 5, Interesting

    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.