Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.lightlink.com!rahul.net!wasp.rahul.net!rahul.net!news.misty.com!news.iecc.com!nerds-end From: Christophe de Dinechin Newsgroups: comp.compilers Subject: Looking for volunteers for XL Date: Tue, 22 Nov 2011 21:03:59 -0800 (PST) Organization: Compilers Central Lines: 61 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <11-11-048@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1322277459 41645 64.57.183.58 (26 Nov 2011 03:17:39 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sat, 26 Nov 2011 03:17:39 +0000 (UTC) Keywords: available Posted-Date: 25 Nov 2011 22:17:39 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: x330-a1.tempe.blueboxinc.net comp.compilers:350 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]