Lambda the Ultimate

inactiveTopic Nemerle
started 2/20/2004; 6:29:47 AM - last post 3/7/2004; 9:44:41 PM
Patrick Logan - Nemerle  blueArrow
2/20/2004; 6:29:47 AM (reads: 10639, responses: 7)
Nemerle is a new hybrid (functional, object-oriented and imperative) programming language for the .NET platform.

Key features of the language include:

  • simplicity,
  • C#-like syntax,
  • easy to use object system (derived directly from the .NET),
  • easy access to both functional and imperative features,
  • powerful code-generating macros,
  • variants,
  • pattern matching,
  • static and on-demand dynamic typing,
  • type inference

I am not sure being .NET compatible qualifies as "easy to use", but the rest sounds interesting. ;^/
Posted to object-functional by Patrick Logan on 2/20/04; 6:32:55 AM

Andris Birkmanis - Re: Nemerle  blueArrow
2/20/2004; 7:23:00 AM (reads: 605, responses: 0)
I wonder, how does it compare to Mondrian, since from the featurelist it looks very similar.

Michal Moskal - Re: Nemerle  blueArrow
2/20/2004; 10:28:42 AM (reads: 524, responses: 0)
It's statically typed (far more in tradition of strict ML-like typing), self-hosting (bootstraping), produces IL bytecode and has powerfull macro system (I'm however not sure if some of the assertions above don't also apply to Mondrian).

One of our main design concerns was to develop languge with functional capabilites that could be used without much problems by C#/Java programmers.

Dejan Jelovic - Re: Nemerle  blueArrow
2/20/2004; 11:05:42 AM (reads: 505, responses: 0)
Sweet. The biggest problem I can see right now is performance. I compiled a couple of programs and then took a look at the produced IL. Objects flying around, boxing and unboxing everywhere.

Most of these didn't have to be objects as the compiler has obviously inferred the right type. I'd say the code generator needs a bit more work.


Mark Evans - Re: Nemerle  blueArrow
2/20/2004; 11:08:05 AM (reads: 505, responses: 0)

One wonders whether .NET is friendly toward functional programming. I've heard that .NET's object-oriented design emphasis makes FP difficult to support. Comments?

Dejan Jelovic - Re: Nemerle  blueArrow
2/20/2004; 11:15:42 AM (reads: 500, responses: 0)
Mark: Not really. Performance is the only problem right now. Three reasons:

1. If you don't do type inference, a lot of basic types are going to be allocated on the heap.

2. Delegates (function pointers) are slooow. They work through reflection, so no wonder.

3. Tail calls are much slower than regular function calls. See this page for some measurements.

Otherwise, it's pretty easy. You can ignore objects if you want, btw. CLR supports stand-alone functions.


Michal Moskal - Re: Nemerle  blueArrow
2/20/2004; 11:57:33 AM (reads: 489, responses: 0)
As for tail calls -- for tail calls to current function we use parameter assignment and branch. This is faster then regular call. General tail calls are slower, as you said (we have them disabled by default for this reason). Exactly now I'm implementing some basic inlining of tail-recursive functions that are just loops.

Ignoring objects is possible, but probably is not the best thing to do (the library is object oriented). Also stand alone functions are not part of CLS (Common Languge Subset, that most programming languages in .NET know).

As for delegates -- we don't use them for functional values. We use simple interface/object approach something like this:

As for object floating around -- there is lots of boxing. This is not going to change, until after we get code generator to use Generics (parametric polymorphism available in .NET 1.2). Then we should see real speed improvement, as the code is going to be specialized at runtime.

However as far as performance goes -- it's not that bad as it first seems from looking at IL -- decent JITs have most basic optmization already implemented so I doubt there are good reasons to do things like constant propagation etc.

On my box compiler compiles itself (about 600k of code, library etc are in another dll) in about 16 seconds (using mono, athlon 1.8+). This should give some impression of performance.

Mark Evans - Re: Nemerle  blueArrow
3/7/2004; 9:44:41 PM (reads: 75, responses: 0)

Well I was about to put this post on the home page but suddenly realized the relationship I had missed. Gont and Nemerle have the same developer. Gont is dead, long live Nemerle. The background information might be useful for those interested in Nemerle. Thank you for keeping it online.

Gont is a programming language, that consists of largely imperative composition of C-like lexical layer, control structures and speed with ML's typesystem, functions as first class citizens, and safety. Plus possibly few more things, like objects.

Hmm...a curious mixture then. Michal Moskal is the proprietor. There is a Freshmeat site for Gont.

Discovered via the GCC Front Ends page.