Looking for volunteers for XL

Hello,


I'm the designer of the XL programming language (http://xlr.sf.net).
This language is designed to make it as easy to extend the language as
it is today to add classes in traditional languages.


It exists in two flavors. One, XL2, is imperative, statically
compiled. The other, XLR, is functional, dynamically compiled with
LLVM.


This is a big project, and I've been at it for years. It is now in a
state where many things work, where the general structure is clear,
but also where a large number of details need to be fleshed out.


So we need volunteers. Badly. In particular in the following areas:


1. Documentation. The web site was lost a couple of years ago, and I'm
not done rebuilding it. Starting with
http://xlr.sourceforge.net/sites/default/files/XLRef.pdf or
http://cc3d.free.fr/xl.pdf, it would be nice to have pages for
generics, syntax, etc on the main web site, but also how-to experience
from folks who didn't write the code in the first place.


2. Productizing XL2: XL2 is quite far along, with things like generics
or meta programming working relatively well. But we need library
contents. We need generic specialization. We need UTF8 support. We
need expression templates or similar meta-programming tricks. And
more.


3. XLR type system: XLR is unique in that it has very few operators.
The tree rewrite operator -> means "transform what is on the left as
what is on the right". It can act as a variable, function, macro
declaration depending on context. It turns out that this makes for a
very "interesting" type system, where you don't have things like
"macros" or "functions", but per-parameter behaviors (i.e. this
parameter is evaluated every time it is used like in a macro, but that
parameter is evaluated before call like for a function). I'd like to
discuss it with like-minded people. I think making this more formal
could be a good PhD topic.


4. Type inference: Knowing that the type system is like nothing else,
I still ventured into trying to implement type inference a la Haskell.
It works relatively well on simple cases, but going from here to a
full-fledged type system is still a lot of work. Right now, on the
cases where type inference works, we are within 15% of the performance
of optimized C. When it doesn't work, we can have a 20x slowdown. So
you see why I'd like to finish this.


So if you feel like you have too much time on your hands, or if
compilers are your thing and you want to take part in creating
something really new in that domain, or if you are just a nice guy who
wants to help, please join us.


[There were a bazillion extensible languages in the 1970s, many quite
sophisticated. They all disappeared without a trace, largely because
the ability to do per-program extensions meant that every program was
written in a different language, making them all unreadable. It turned
out that semantic extension, a la C++ overloaded operators, is a lot
more usable than extra syntax. I assume you're familiar with EL/1,
IMP-72, et al, so why is this any better? -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.