The Nemerle Project Blog

If you want my advice -- never write a metric truck load of code to debug it later. I'm still trying to debug the new type inference engine I wrote. 18 out of 60 dots of Nemerle.Compiler.dll are eaten :-) (ncc displays progress bar consisting of dots, that are replaced by underscores). This is getting annoying.

But, from the good news, some time ago we were discussing idea of adding new stuff to existing library classes. For example you have the System.String class and want the Nemerle.Utility.NString.Split static method, that works on lists and not on arrays, to be one of the regular String.Split overloads. We're not interested in really extending the class -- some syntactic sugar should be enough.

This seems doable, it is still in the design stage. The idea come back when I read this discussion on the ocaml-lib-devel mailing list. It was about the implementation of the VList data structure, that is another storage architecture for immutable ML-like lists. The benchmarks are quite promising -- it is much faster than the regular list for most operations. And taking into account that OCaml has a very good, precise garbage collector -- it gets even more interesting.

So the idea was to replace regular lists in Nemerle with vlists, and see what happens. Converting lists constructors isn't very hard, just a small compiler hack. The hard part is matching. Matching on lists in Nemerle looks like this (you can use the :: syntactic sugar that is really used in the sources in comments):

match (some_list) { | list.Cons (x, xs) => // x :: xs do_something_for_head (x); do_something_for_the_rest_of_the_list (xs); | list.Nil => // [] do_something_else () }

while the list data type definition looks like this:

variant list [T] { | Cons { head : T; tail : list [T]; } | Nil }

So the idea Kamil and I come up to was to annotate VList like this:

class VList [T] { public enum State { | Cons | Nil } [MatchOnThis] public TheState : State { get { ... } } [FieldInOption ("Cons")] public Head : T { get { ... } } [FieldInOption ("Cons")] public Tail : VList [T] { get { ... } } // the real implementation of vlists... }

The [MatchOnThis] macro would produce VList.Cons and VList.Nil bogus members, while the [FieldInOption] macros would add specific members to them. So the macthing like:

match (some_list) { | VList.Cons (x, xs) => do_something_for_head (x); do_something_for_the_rest_of_the_list (xs); | VList.Nil => do_something_else () }

would be possible. What would remain then would be changing the builtin [...] and :: literals to reference VList instead of list.

The idea is somehow broader. For example we could add matching to XML elements this way. Now we need the extending-existing-class part.

extend class XmlNode { [MatchOnThis] public NodeType : XmlNodeType {} [FieldInOption ("Attribute")] [FieldInOption ("Element")] // ... public Name : string {} [FieldInOption ("Attribute")] [FieldInOption ("CDATA")] // ... public Value : string {} // ... } match (some_xml) { | XmlNode.Attribute (name, value) => ... | _ => ... }

Anyway, just an idea ;-)

-- Michal

The Blog

06 Mar 2005: Dots, vlists and matching