Slashdot Mirror
XL Compiler Bootstrapped
descubes inputs: "An XL compiler bootstrapped two days ago (that means it compiled itself). Take a look at the project homepage to discover this language, designed around concept programming ideas, which is a sort of cross between C++, Lisp and XML. Much help is now needed to improve this rudimentary first iteration." One thing to note is that the C++ version of the compiler came in at 4500 lines, while the XL equivalent came in at some 2700 lines. This seems to imply that XL may be easier to work in than C/C++. Might XL someday be nudging the old workhouse out of a job in the near future?
I would tend to disagree. There have been many studies that show that the same programmer will on average produce approximately the same number of codes in any given language. A language that offers better abstraction, will therefore give higher programmer efficiency.
To me, "better" means to more readable, more maintainable, compiles to better object core, etc, etc. Who cares how many lines it needs?
True, there are other considerations. Python will usually make you more efficient than, say C++. But well-crafted C++ code is likely to run faster. The holy grail is good abstractions, easy (but safe) low-level access, small run-time, and fast code. I wouldn't be surprised if concept programming was a step in the right direction.
No. Concept-programming focuses on the limits of abstractions, and consequently on the techniques that help building better abstractions. Concept programming is not what people do. I wish, but it just ain't so. This is discussed ad-nauseam on the Mozart web site.
I read the code for the compiler itself, and didn't really see the kind of abstraction I really wanted to see.
This is really interesting to me. What kind of abstraction would you have wanted there? Please note that the bootstrap compiler is very limited, like any bootstrap compiler, so I can't make use of many fancy features of the "theoretical" XL. But I'm relatively proud of the "translate" extension, for instance (http://xlr.sf.net/031105.html). I think this is a good example of higher-level abstraction. And it's what makes the XL version shorter than the C++ one.
While you can go ahead and create domain specific abstractions with syntax, the code to implement a nontrivial abstraction with reasonable semantics and syntax is equally or *more* complex than just using either domain specific tools separately, or using basic functional abstraction in the first place.
That is just not true. One data point: the symbolic derivation in XL (http://mozart-dev.sf.net/derivation.html) is a few hundred lines of code. The corresponding C++ equivalent using template meta-programming is a few thousands lines of code. The derivative expansion in the source code is shorter than the derivative meta-processing code if you use it only once. Just like inlining the code of a function is shorter than adding all these pesky prototypes if you use the function only once.
You can implement every abstraction buzzword ever mentioned with functional decomposition combined with a preprocessing pass. The important part is not the mechanics, since every programming language since lisp has these mechanics.
The objection "it's easy to build, here are the tools" is not a valid one in my opinion. "It's easy to build a kernel, all you need is a C compiler". Yeah, right.
The important part is the interface to the programmer... and that's a tough problem
And that's precisely where XL and Lisp differ the most. I think XL is more accessible to a majority of programmers, and can appeal to some who would not touch Lisp with a ten foot pole. Yet under the hood, it is so much like Lisp that Lisp-enabled programmers who would not touch C with a ten foot pole could like XL.
I believe you have a good background and could add valuable contribution to the project. Why don't you try to take "one more stab" at this kind of mutable language? ;-)
-- Did you try Tao3D? http://tao3d.sourceforge.net