The Nemerle Project Blog

This is preview release before 0.3.0, which is real soon now. There are lots of changes in this version -- the parser and the typer (which constitute more then half of the compiler) have been replaced by entirely new implementations.

There is a number of backward incompatible changes in this release. Most of them were previously discussed on the mailing list, and received rather good feedback other only generate warnings in this release. We apologize for both. We hope they make Nemerle a better language. On the plus side -- we should be now far closer to certain language stabilization point.

0.3.0 should bring implicit conversions, List iterators as list[T] methods and maybe some more goodies.

Incompatible language changes:

Variant options are now nested inside enclosing variant, so their names need to be prefixed with variant name. For example: You can mark variant with [ExternallyVisibleOptions] to import its options outside the variant or open variant name with using. More details in this thread.
Generic types use now [] instead of <>. That is there is list [int] not list <int>. This is the second (and hopefuly last ;-) time we change it. More details in this thread.
Record patterns like { foo = 42; bar = 3 } are now deprecated. New where patterns have been introduced, to explicitly mark the class used for matching: Variant patterns now also support field names:
The : operator in patterns should from now on be only used to statically enforce type. Runtime type checks should be performed with the is operator which uses the same syntax: Trying to use : or is in the other context will rise warning. It will be hard error for : used as is in future release.
The catch handler syntax has been changed to reflect change in matching:
Macros can no longer be nested in classes

Language additions:

Added <<, >>, |, ^ and & operators. %|, %^ and %& remain there.
It is now possible to ignore values like this:
It is now possible to assign stuff to tuples, like this:
Function parameters can be now marked mutable.
The partial modifier on classes is now supported.
{ def _ = foo; } is now allowed without the additional () at the end.
New throw; expression to rethrow the exception.
The type inference engine has been replaced by a new one:
- code like this compiles fine: when the type of some_list is known.
- overloading resolution now works when passing functional values:
- variant option's constructors have now proper type, that is there is no longer need to SomeVariant.Option () :> SomeVariant.Option
- stuff like array [A (), B ()] should now work (if A and B have a common supertype)
Add repeat (times) body language construct

Library changes:

IMap.Fold used to use reverse parameter order then other fold functions. It is fixed now.
A new Set class has been added.
Nemerle.Collections.Vector is now enumerable (patch by nuffer).
New functions in List:
- MapFromArray
- GetElementType
- Contains
- ContainsRef
- FirstN
- ToString (separator : string)
List Length() and IsEmpty() are now properties.
New functions in Option:
- Iter
- GetHashCode override
Stack.Top() is now a read/write property.

Macro library changes:

Concurrency macros based on implementation of Polyphonic C# has been added (implemented by Ricardo).
The foreach macro now uses semantics consistent with matching: foreach (s : string in foo) requires elements of foo to be of statically known type string, foreach (s :> string in foo) casts each element of foo to string (raising exception in case of problems) and foreach (s is string in foo) executes the loop body only for strings in foo.
Assertions macros now have new syntax extensions available. They can be used like in http://nemerle.org/macrouse.html#designbycontract
Added macro library for type-safe SQL operations with MS SQL Server
Diagnostics macros now have parameterless Trace macro and time macro for measuring performance of some chunk of code
Quotations of patterns, types and expressions are now unified to simple use of <[ some code ]>
Added OverrideObjectEquals macro for automating overriding of Equals (object) method with type-safe Equals (SomeType) method

Other stuff:

Parser has been changed, it gives better error recovery, forward lookup and capability of deferring parsing in syntax extensions (see here)
We have a new tool -- a C# to Nemerle converter. It produces human-readable Nemerle sources.
We have added over 300 converted testcases from MCS. ncc behaves now far more sane and C#-like especially at the class level.
The -doc switch can be now used with NDoc. Example output can be seen here.
Some warnings can be now disabled by-number, there is also -warn warning level switch.
Simple Nemerle interactive shell has been included in the distribution.
The debug symbol output should work under MS.NET.
The Sioux webserver has been greatly extended.
A syntax highlighting file for Midnight Commander editor.
The htmldumper tool has been written -- it creates pretty Nemerle sources for the web.
It should be now easier to compile Nemerle on Windows using MinGW.
Lots of performance work -- in the compiler, the library and the generated code.
Lots of bugs hunted.

"Variant options are now nested inside enclosing variant, so their names need to be prefixed with variant name."

A disadvantage of requiring the prefix is that people might start using artificially abbreviated type names to reduce the amount of typing.

The Java compiler has a special case for "switch" on enums so that you don't need the prefix. Woudln't this work for "match" in Nemerle? Though you'd probably still need the fully qualified name during construction, at least it would eliminate redundancy for "match".

On the type parameter syntax...the C# language reference cites a similar example:

> f(x < foo, y > (a+b))

This could be parsed in two ways:

> f ( x<foo,y>( a+b ) ) // call generic function "x<'a,'b>(...)"
> f ( x<foo, b>(a+b) ) // "f" takes two boolean parameters

If I remember correctly, they don't resort to checking the types of the different terms. They use some weird heuristic check on the tokens to guess which one is intended. Gross. The brackets are a much better way to go.

> A disadvantage of requiring the prefix is that people might start using artificially abbreviated type names to reduce the amount of typing.

Actually our problem was the reverse. In our expirience it was a common pattern to
prefix name of each variant option with some strange abbreviations:

variant ParseExpr {
| PE_Ref { name : string }
| PE_Call { fn : ParseExpr; parms : list [ParseExpr] }
}

variant TypedExpr {
| TE_Ref { name : Symbol }
| TE_Call { fn : TypedExpr; parms : list [TypedExpr] }
}

so we can distinguish ParseExpr Ref from TypedExpr Ref. Now we have ParseExpr.Ref vs TypedExpr.Ref - indeed in compiler we use PExpr.Ref and TExpr.Ref, which *is* using "artificially abbreviated type names" as you mentioned. But it is still much better than using those abbreviations are part of variant option name.

Moreover, with current solution you can create alias for type name, like

using PE = ParseExpr;
...
PE.Ref -- resolves to -> ParseExpr.Ref

or even open this type name globally:

using ParseExpr;

Ref --- resolves to --> ParseExpr.Ref (if it is not ambiguous)

The same holds for enums. We just decided, that C#'s design for enums is reasonable and used it for both variants and enums.

> If I remember correctly, they don't resort to checking the types of the different terms. They use some weird heuristic check on the tokens to guess which one is intended. Gross. The brackets are a much better way to go.

Correct, it is a hack in the parser. They decide on token after closing >, if it
is (, etc. expression is parsed as generic type specifier.

In Nemerle it won't be a great problem, because you rarely have to write generic
specifier. Type inference engine can handle it in most cases, like

def x = Dictionary ();
x.Add ("bal", MyVal ());

in contrast to C#'s

Dictionary <string, MyVal> x = new Dictionary <string, MyVal> ();
x.Add ("bal", new MyVal ());

Unfortunately, sometimes it is necessary to specify types manually:

class A [T] {
}
...
def x = A .[int] ();

We use different syntax here (maybe somebody have better ideas?), because

def x = A [int] ();

would create ambiguities with indexers, like

A [x : void -> Foo] : void -> void { ... }
...
class A [T] { }
class Foo { }

A [Foo] (); // can resolve to get_A (Foo) ();
// or to A .[Foo] ();

Thus we decided to use a little bit changed syntax, because it won't be used often anyways.

"Actually our problem was the reverse. In our expirience it was a common pattern to prefix name of each variant option with some strange abbreviations:"

Yeah...I see that a lot in Haskell code. But what I was suggesting is making the prefix optional in "match" statements, but still requiring the prefix for constructors.

variant ParseExpr {
| Ref ...
| Call ...
}

variant TypedExpr {
| Ref ...
| Call ...
}

x = TypedExpr.Ref("x")

// Since we know 'x' is a TypedExpr, we don't have to
// specify the prefix.
match (x) {
| Ref ...
| Call ...
}

It wouldn't be ambiguous in this case, right? This is what the Java 1.5 compiler does for enums.

Actually this wouldn't play well with type inference. For example
consider:

def foo (x) {
match (x) {
| Ref => ...
| Something => ...
}
}

it is actually possible to type this code, once you see foo (TExpr.Foo()).
But there are cases when you don't see it. It is possible to implement this,
though with some extensions to our typing engine (a day or two of work).
I generally like the idea, but have some doubts if it is going to make
the code cleaner and easier understandable, so I would like to have it
discussed more.

Hi! http://www.ringtones-dir.com/get/ ringtones site. ringtones site, Free nokia ringtones here, Download ringtones FREE. From website .

The Blog

22 Mar 2005: Nemerle 0.2.9 released!