Home | About | Partners | Contact Us

Quick Links Home News Status Building XL XL Mailing List Understanding XL Conceptual overview XL examples Inside XL Concept Programming In depth Browse GIT Bugs SourceForge Info Contact Other projects GNU Project The Mozart Project

XLR: Extensible Language and Runtime The art of turning ideas into code XL, an extensible programming language, implements concept programming If you want to know more, you should start here. Comment to ESR's announcement about "C++ considered harmful" Monday, October 13, 2008 This is a comment to the C++ considered harmful blog entry Eric Raymond posted last month. Eric, I agree with Jeff that writing about the problems of C++ will only be effective if you can offer something that is better. Consider your own critique of the Unix Hater's Handbook: the best chapters were those where the authors had something better in mind that they could use as a reference. I believe you suggest that Python or similar languages are the "better" solution in the language space, but as many have pointed out, there are many things C++ can do that Python can't. Let me respectfully propose my own biased answer. Designing a modern language is a problem I have thought about long and hard for a very long time (I'd say 15 years). The result is the XL programming language, and a programming paradigm I called concept programming. Highly idiosyncratic, certainly, and even more highly confidential at this point. But I think it's worth sharing with you. Your criticism of C++ will be stronger if you know of other ways to achieve the same goals as C++ than if you suggest that we should change the goals. And to make it clear, the goal in my opinion is to be able to develop very large and complex programs that still take advantage of the machine to the maximum possible extent. In other words, I am not ready to sacrifice performance or memory usage for convenience, and I don't think we should have to. Many commenters here expressed the same feeling. So how exactly is XL improving relative to C++? First, XL stands for "Extensible Language". The initial intuition is that the problem set is not bounded. So I wanted to create a language that made the code representation of arbitrary concepts possible, not just "functions" or "objects". Actually, it should not just be possible, it should be easy. To illustrate, it should make it just as easy to add symbolic differentiation to the language as it would be to add a class in C++. I wouldn't comment here if I didn't think I have achieved that objective. But it goes further. When you start thinking in terms of concepts and representations, you start seeing flaws in other languages and designs that are not obvious, and you start designing things in a different way. Highly idiosyncratic, I told you :-) In short, instead of a monolithic compiler like practically everybody else has done so far, XL has a tiny compiler core implementing a standard syntax, and a number of compiler plug-ins that cooperate to implement the language. Let me illustrate this with things that you or your readers seem to care about: efficiency, code density, high abstraction levels, operator overloading, preprocessing, garbage collection, rapid prototyping, quick build cycles, interaction with other languages such as C, simple syntax. Obviously, that won't be a short post... Efficiency: XL was designed to have machine code as one of the primary targets, and to take advantage of modern architectures. Modern architectures differ from the dominant architectures when C or C++ were designed, in at least two important ways. First, memory accesses are no longer cheap. Second, accelerators and "strange" computational models are everywhere. Memory accesses are extremely expensive, so mandating pointers for things like parameters (references or const refs are the default for most template code in C++ for a reason) or objects (the infamous 'this pointer') are things we should consider fixing. XL has explicit output parameters which it can pass by copy if more efficient (the Itanium ABI defines four 64-bit output registers), and can define objects without any implicit pointer reference. In one micro-benchmark involving complex number computations (for fractals), XL was 70% faster than C++ on Itanium, because it replaced loads and stores with register accesses. And I could easily have done more computations between loads and stores to tilt the balance even further. Machines are no longer uniform, there are co-processors for a number of key tasks, and even mainstream CPUs keep receiving new instructions that don't fit in the limited C++ computing model, such as vector arithmetic or multimedia operations. In XL, all operators are defined in the library, so adding new built-in types and a default implementation is not a problem at all. Similarly, XL can easily represent GPU programs in a way that hopefully will soon make ugly hacks like OpenCL unnecessary Code density: XL tries to eliminate what I call syntactic and semantic noise. I invite you to compare the C++ implementation of complex arithmetic with the XL implementation (which, it should be noted, only implements a small number of operators at this point, so you should look at the code and not count lines). In general, XL generic code compares very favorably to C++ code, in particular because generic types behave like real types, e.g. you can define functions with them without having to repeat all the "template" declarations. High abstraction levels: Thanks to the extensibility mechanisms, XL makes it possible to add your own abstraction levels. Like C++, you can create your own pointer types. Unlike C++, this is how the language's most fundamental types are defined: integer, real, pointer, array are all library types. Being able to define such abstractions is a testimony to the power of the approach. But of course, abstractions at a much higher level is what makes things really interesting. Again, what makes it possible to compile the differentiation notation in the code is this plug-in, a mere 191 lines of code including comments. Contrast this to the C++ implementation (I can't find a full working implementation on the web anymore, but from memory it required something like 4000+ lines of really hairy C++ code). The XL templates system is also pretty good, allowing one to define Maximum the way it should be, something that will only become possible (barely) with the upcoming C++ 0x standard. Operator overloading: XL features something I called "expression reduction", which is operator overloading on steroids. Instead of overloading operators, you overload complete expressions. So you can optimize the memory access patterns for matrix linear algebar (A*B+C), or define specific shortcuts notations (X=0 without allowing X=1). This works for templates as well (XL calls them generics), so you can for example write "pointer to integer" or "array [1..5] of real" and have expression reduction reduce that to the right instantiation. Preprocessing: The XL pre-processor is powerful enough to compute factorials or implement an assert macro that fails at compile time if it can determine that the condition is false statically. Garbage collection: This is not implemented yet, so I won't boast about it, but my current design should allow you to garbage collect data structures in a file or network connections once it's complete. Rapid prototyping: In my opinion, so called "scripting languages" stand out not just by their interactive nature, but also because they offer a wealth of everyday features that often includes the kitchen sink. I expect XL to mature in that direction, but at the moment, its library is pretty much empty. Code submissions are welcome, though: it's open source. Quick build cycles: One reason C++ is bad in that respect is that it still relies on the very ugly include-file based modularity inherited from C, which doesn't scale well for a language that is complicated to analyze. XL has include files, but they are definitely not used much for standard modules. The XL syntax is also really simple and parses very very quickly relatively to C++. Now, does this result in faster builds? Not necessarily, because other things get in the way: extensibility and flexibility of notations have a cost. Also, I realized quickly that some concepts such as aspects apply to the program as a whole. The XL compiler itself uses such a whole-program extension to implement plug-ins. So between very fast parsing on one side and occasional whole-program passes, we'll see how this plays out in the end... Interaction with other languages such as C: XL is designed to interface with a number of incompatible runtimes. So the notion of "runtime" was built into the language. A large fraction of its tests can be compiled to C or to Java runtimes, for example. Interfacing with C is pretty easy too: function Allocate_Memory(size : unsigned) return pointer is C.malloc Simple syntax: The syntax of XL consists in a very small number of rules. The whole parser is implemented in 611 lines of XL, including comments, and the scanner is another 469 lines... There isn't a single line of Bison or Lex in the whole thing, another idiosyncracy. You can always parse an XL source without having to analyze it, this is a fundamental requirement if you want compiler plug-ins to cooperate. To most people, XL code looks like pseudo-code, except that it isn't. There are other things I did not even talk about, like how XL will deal with real-time or parallelism. Can you guess I'm proud of my language? OK, it doesn't exactly have a cult following yet, and a lot of work remains to be done. But hey, I hear you are good at evangelizing stuff, so if you like it, why don't you talk about it and send good programmers my way? ;-) October 2008 Sun Mon Tue Wed Thu Fri Sat 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Sep  Nov Copyright 2009 Christophe de Dinechin (Blog) E-mail: XL Mailing List (polluted by spam, unfortunately)