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?

4 of 80 comments (clear)

  1. User Interfaces for programmers by ezy · · Score: 2, Informative


    "Concept"-based programming is the only programming people do.. In non-buzzword terms, it's abstraction. Whether you abstract over code, or data, semantic or syntax... it's all basic abstraction. I read the code for the compiler itself, and didn't really see the kind of abstraction I really wanted to see..

    I've taken a stab at this kind of mutable language, and I'm sure more than a few others have, but there's always something missing. It's the same problem that occurred in one of the original mutable languages, LISP (+ macros). 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. Nevermind the added complexity of trying not to break anything else in the language at the same time.

    After a while, I realized the nut that I, and many other people, were trying to crack is slightly different. 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 important part is the interface to the programmer... and that's a tough problem...

    1. Re:User Interfaces for programmers by descubes · · Score: 4, Informative
      "Concept"-based programming is the only programming people do.. In non-buzzword terms, it's abstraction

      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
  2. Re:So exactly what is the language? by descubes · · Score: 2, Informative

    There are many examples on the "old" web site (http://mozart-dev.sf.net/xl.html, linked from the main XL web site). On the new web site, the only real example is the compiler itself ;-)

    --
    -- Did you try Tao3D? http://tao3d.sourceforge.net
  3. Re:A Quick Glance by descubes · · Score: 2, Informative

    In the "old" compiler (the one on http://mozart-dev.sf.net) iterators are implemented, though not exactly in the way C++ does it. You write:
    for <some expression> loop
    and the compiler looks for an iterator that matches . This is how for I in 1..5 loop or for element in array loop are implemented.
    In other words, iterators are directly used by the compiler in for loops. This doesn't work in the bootstrap compiler (yet).

    --
    -- Did you try Tao3D? http://tao3d.sourceforge.net