Student’s team from University of Wroclaw (Poland), developing new .NET platform hybrid language Nemerle, get a grant from Microsoft in the amount to 25 thousand EURO. That was a reward in a competition which was in connection with the ROTOR platform. Mono was also used.
Get to Know Nemerle
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
One step closer to Lisp (actually, Dylan) for .NET
What the hell is the point of all this? How is this any better, some points I see but really is another .Net language necessary?
Actually, .NET needs something like this. Nemerle seems to be a pretty modern language, with a lot of good features. For example:
– Its got functional features like lambda (called functionals in Nemerle). Lambda opens up a whole new world of design techniques. Lambda also unifies a lot of things (like iterators, delegates, etc) that are individual concepts in C#.
– Its got type inferencing, which makes lambdas a lot less cumbersome to use, and makes refactoring a lot easier, because you don’t have to bother typing in declarations the compiler can figure out anyway.
– Its got pattern matching. No more deeply nested “if-then-elseif-else” code. Makes things much easier when doing functional programming.
– Macros! With macros, you can easily extend the language. Very simple example of the power of macros: Dylan doesn’t have an enumeration type. Its a matter of a few lines of easily understood code to add macros to the language. Stuff like that just scratches the surface. Indeed, in Dylan, much of the language itself (for lops, switch statements, etc) is macros over a simpler underlying core language. In Common Lisp, macros are even more powerful. Macros are actually programs that operate on the code given to it. Thus, they can extend the language in arbitrarily powerful ways. It looks to me like Nemerle has pattern-matching macros (like Dylan and R5RS Scheme) rather than fully-general procedural macros. That makes sense, given that its really hard to do fully-procedural macros in an infix-syntax language.
Actually macros in Nemerle ARE fully-general procedural macros. You can execute any code (do any computation) at compile-time, decompose any code (as syntax tree) and create any code.
Our definition of syntax extensions are very weak currently (they are distinguised by first unique token – keyword). For example ‘if’, ‘for’, ‘while’, etc. are all macros translating related constructs to “core Nemerle”.
We think macros in this form are quite new not only in .Net world, but also to entire programming languages (similar works on Template Haskell, MetaML are mostly from 2000+)
Will it be possible to use libraries written in this language from other .NET languages?
“Actually macros in Nemerle ARE fully-general procedural macros. You can execute any code (do any computation) at compile-time, decompose any code (as syntax tree) and create any code. ”
So it is a bit like C++ template metaprogramming, only with a sane syntax 🙂
Hmm. It looks like the macro system allows for arbitrary computation, but it doesn’t seem procedural to me. The decomposition/composition of the syntax trees seems to happen through pattern matching, which implies to me that its a functional macro language, not a procedural one. It does seem nice that it allows for arbitrary computation during macro-expansion, though. Scheme and Dylan macros don’t do that.
In any case, I’m curious about your last statement. What do macros in Nemerle do that macros in Common Lisp do not?
From nemerle.org:
We plan to make the language full CLS consumer and producer soon.
And yes, we currently compile to .NET binary libraries, which can be loaded by any other .NET program (we are also going to create wrappers to our standard library in C#, so using our datastructures would be easy)
I suppose you liked writing programs embedded into language type-system 😉
Well, C++ templates prove, that there is much need for metaprogramming in industry. So we go 🙂
C++ template metaprograms are only fully-general in the sense that its Turing-complete. When I say “fully-general” I mean that anything you can do in regular code, you can do in a macro. That includes connecting to a network and downloading the macro body from the internet
…only run at compile time though.
So ok, I don’t fully understand what you mean by procedural vs. functional – our macros looks like common functions
printf (“%d”, 3)
it is a macro, which analyzes “%d” at compile-time and make entire procedure type-safe. They are although not exactly functions (can’t be passed be parameter, aren’t recursive), but they can use any function, so it is a minor disadvantage.
And as C++ templates are turing complete, they are not handy in usage as general purpose computing functions.
> In any case, I’m curious about your last statement. What do macros in Nemerle do that macros in Common Lisp do not?
Well, you might not agree, but we thinks mainly syntax and ease of use… But seriously – static typing of generated code, hygiene (well, Scheme got it, so we will soon), quite nice idea of macros on type declarations:
[SerializableXML (“consumer.xml”)] class Consumer { … }
SerializableXML is a macro, which adds method ‘SerializeXML’ to class. And well, we hope that macros can be so widely used like C++ templates (exist in mainstream language).
Okay. Let me see if I understand correctly. Nemerle macros are kinda like Scheme macros, except they allow arbitrary computation? If so, that’s what I mean about “functional macros” vs “procedural macros.” Its kind of like the difference between Scheme’s syntax-case macros (procedural) and its syntax-rules macros (functional).
We’ll probably disagree on syntax and ease of use (I like prefix myself). Depending on what you want to do, Common Lisp’s macros can be harder or easier than pattern-matching macros. For example, there is a feature in Common Lisp called compiler-macro’s. They let you implement a code-optimizer in a macro, to optimize domain-specific code that your compiler cannot. Doing something like that would be a little bit hairy without a procedural macro system.
Maybe the worst fact is that I don’t know much Lisp or Scheme. These languages have developed really much research and practice in macro processing. A read a few papers about them and I know that Lisp/Scheme community have built these languages in much scope from macros.
As I’m not able to give you clear comparison of Nemerle to these systems, I will try to state what I think differ most and for sure:
– language, macros and generated code are statically type-checkced; as I know Lisp isn’t type checkced language, so I see clear advantage here
– entire language is much different, so also quotation of code, using macros, compiling them is quite different (more alike imperative languges)
– as I mentioned above, macros processing type declarations, I didn’t hear about any language doing such things
For better comparison and more information you can look at http://nemerle.org/metaprogramming.pdf
Of course our meta-system is under heavy development and is subject to change. Any comments and suggestions apreciated.
(Hmm, I thought Scheme macros CAN execute any code, but I’m not sure)
This sounds like an interesting language, but I haven’t yet been able to bring up the site to find out more about it. Was it OSNews’ed? I’m interested in language implementation issues on the various platforms so any info about this language would be appreciated, especially if that info is on a working site.
Thanks in advance!
Okay, I think I get it. Some points, though:
– Common Lisp code can be type-checked. Its kinda like the reverse of Nemerle. Common Lisp is a mostly dynamic language, with some static typing, while Nemerle appears to be the reverse.
– I’m not entirely sure what you mean by macros processing type declarations. Macros in Lisp/Scheme/Dylan can process arbitrary code, including type declarations. In Dylan, the syntax used to define classes, functions, methods, etc, are all just macros.
– There are several Scheme macro systems. syntax-rules, the traditional one, is a pattern-matching macro system. You get input code, and you use templates to specify what the output code should look like. syntax-case receives code as lists, and manipulates those lists using arbitrary Scheme code. The latter are what I’d consider procedural.
Ah, I see the metaprogramming link is much more informative then the lecture. From the appearances of it, Nemerle’s macro system appears to be something between Scheme’s syntax-rules and syntax-case. It allows you to execute arbitrary code, but you seem to do tons of pattern matching to get around the infix syntax. In CL macros, you can easily deal with the compiler-internal parse tree, because its just a list. CL also has something like Nemerle’s quasiquote, also called quasiquote.
Anyway, I have to say I’m happy to see a language that puts some importance on macros. Macros are extremely powerful additions to a programming language, and its *long* overdue.
Some parts of the language remid me of ML.
Since Microsoft Research is playing with other ML based languages like F#, could it be that we will finally see the
support of a big name for functional languages?
Info on F#
http://research.microsoft.com/projects/ilx/fsharp.aspx
Personally i don’t think i would use this language, but i wish the developers all the best. I hope they are not too dependent on Microsoft grants or else it may become a half-baked .Net implementation like Python.
Site’s back!
It looks like an interesting compromise language. I don’t mean that in a bad way, the language seems to be very pragmatic. If you assume that the language needs to be able to support the semantics of the CLR, they managed to implement most of the more useful functional language features while not dropping anything really necessary. The syntax seems less problematic than most C-like languages, and simpler to use without error than most functional languages, particular to functional language newbies.
The macro facilities look to be quite useful. The basic idea seems to be that the lexer stays the same, but the parser is up for grabs – roughly comparable to REBOL in language extension power (with a C-like syntax), but not as powerful as Perl (not a bad thing, it’s less error-prone that way). A heck of a lot better than the macro facilities in any other language with a C-like syntax, at least in my experience.
The type inference looks promising, as does the pattern matching. I would like to see how they eventually manage to integrate their variant types with the other CLR languages and how well pattern matching works with objects. We’ll see.
The semantics of the language seem to really need the .NET 1.2 extensions like generics. At least they are testing on the Mono platform so they can get a preview of that – hopefully Microsoft will catch up soon.
It does seem a little ironic that in an expression-based language they have changed assignment to return void, making it useless to chain assignment expressions. I like that they’ve done this though – C-like languages have a lot of features that lead to frequent coding errors but the syntax differences of Nemerle prevent a lot of those.
I understand why Microsoft would like this language: They’ve always seem to prefer the pragmatic, even when it annoys everyone to do so. Congratulations on the award!
I look forward to the further development of this language.