Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

XL Compiler Bootstrapped 80

Posted by Cliff from the major-milestones-surpassed dept.
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?
This discussion has been archived. No new comments can be posted.

XL Compiler Bootstrapped More

XL Compiler Bootstrapped

Comments Filter:

  • 4500 vs. 2700? (Score:3, Funny)

    by rekkanoryo ( 676146 ) * <rekkanoryo AT rekkanoryo DOT org> on Sunday November 09, 2003 @08:32PM (#7430933) Homepage
    That's a huge difference in line count between the two versions. If XL is that good a language, it may be worth learning. Now maybe I can get that 1400-line C++ program I've been working on for a year to be less than 1000 lines!
    • Its a big mistake to confuse number of lines with a "better" language.
      To me, "better" means to more readable, more maintainable, compiles to better object core, etc, etc.
      Who cares how many lines it needs?

      • Re:4500 vs. 2700? (Score:3, Interesting)

        by Curien ( 267780 )
        While you're correct that LOC is not a measure of how good a language is, it can be a rough measure of the level of abstraction afforded by a language, when compared to a similar language.

      • Re:4500 vs. 2700? (Score:5, Interesting)

        by joto ( 134244 ) on Sunday November 09, 2003 @10:20PM (#7431472)
        Its a big mistake to confuse number of lines with a "better" language.

        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.

      • i agree completely. LOC really has nothing to do with the quality of the code either. like while (thing 10) { thing++; } is only 3 lines, but it does not make it any more better then: while (thing 10) { thing++; } both really are just as readable. Also, when dealing with stuff like C++, u can discover while VB does things in less code, a game coded in VB will probably never run as well then a c++ equivilent. Looks a bit like eiffel to be honest.. Of course, I cant say anything until I've tri

      • Re:4500 vs. 2700? (Score:3, Insightful)

        by jilles ( 20976 )
        Lines of code is indeed a pretty bad abstraction for complexity. I always prefer a little verbosity (e.g. using more than one character for variable names, always use brackets for blocks, even though they are one line only). However, if an equivalent program takes up significantly less space in a particular language that can point out poor levels of abstraction in the other language. The general trend of new programming languages is that they reduce the amount of lines of code needed for programs (and, iron

        • Re:4500 vs. 2700? (Score:4, Interesting)

          by descubes ( 35093 ) on Monday November 10, 2003 @09:28AM (#7433433) Homepage
          IMHO one of the major problems of modern programming languages is its reliance on ascii as the storage and editing medium. Most of the innovations in IDEs for example try to work around the fact that the program is stored in ascii by maintaining a parse tree of the entire source code. This allows for all sorts of on the fly transformations (refactoring) and presentations (e.g. uml diagrams).

          Yes! You nicely pointed out some of the reasons for a standard syntax tree representation [sf.net] in XL. The properties you mention (accessibility to third-party tools, persistence, representability to the programmer ("rendering"), extensibility (more data than in the source)) are all important, and discussed on the Mozart web site.

          The "new" XL compiler, the one that bootstrapped, is an attempt at vastly simplifying that tree representation. It's now down to 7 node types.

    • The main source of the difference is that I made use of XL's extensibility (meta-programming) to add an extension to the language for use in the compiler (an example of domain-specific extension). See the "translate extension" post http://xlr.sf.net/031105.html.

      So, in that particular case, I believe that the difference really represents a difference in the level of abstraction.
    • You can probably get it down to a single line of perl, tho the terminal may wrap a few times.
    • My guess is that this probably has something to do with the fact that some languages have the ability to natively parse their own code. I know this is the case with scheme. I know this language is based of lisp as is scheme, so I'm geussing that this is probably part of the reason why there is such a huge difference in the. The XL version probably doesn't have to deal with memory management or raw parsing of the text. I wrote a scheme interpreter in scheme for a class and its at someting around 800 line
    • > That's a huge difference in line count between the two versions.

      Huge? Hardly. Statistically speaking, it's barely significant. It's
      within one order of magnitude, for crying out loud.

      If they'd written it in Perl, it'd be three hundred lines including comments
      and some clown over at perlmonks.org would be trying to golf it down small
      enough to fit into a signature.
  • Would braces count as lines?

    if (X == Y)
    {
    Z = X * 2;
    return Z;
    }

    I'd be happier if the braces were in the language... using white space seems intangible.
    • XL is mostly defined by its parse tree. As you can see with the Moka example (a Java parser) on the Mozart web site (http://mozart-dev.sf.net/moka.html), I have nothing against writing a parser for a brace-enabled language ;-)

      In XL, braces are used for pragmas, i.e. compiler plug-ins. If you write {derivation} dsin(x)/dx, it tells the compiler to hand over the dsin(x)/dx parse tree to the derivation plug-in. See http://mozart-dev.sf.net/derivation.html for an example.

      For program structure, I prefer to use

  • XL? (Score:2, Funny)

    by Ricwot ( 632038 )
    I'm a fan of english, now if only a programming language was:

    "be a calculator"

    and that was it, I'd be so happy!

    • Re:XL? (Score:4, Funny)

      by egrinake ( 308662 ) <`erikg' `at' `codepoet.no'> on Sunday November 09, 2003 @09:05PM (#7431117)

      "When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop."

      -- Alan Perils

      :)

    • I'm a fan of english, now if only a programming language was:
      "be a calculator"
      and that was it, I'd be so happy!

      That will almost work.

      Unfortunately the user interface of the calculator leaves a little to be desired. For instance to add "2 + 2", you need to do the following:

      type "mov ax, 02" followed by <enter>
      type "mov bx, 02" followed by <enter>
      type "add ax, bx" followed by <enter>
      type "push ax" followed by <enter>
      type "call DECIMAL_OUTPUT_ROUTINE" followed by <enter>
      type "
    • Fatal Exception Occured.

      Computer: "To be or not to be a calculator, that is the question."
  • This is why we need something like .NET

    I often wish to use programming languages other than C++, but the library bindings aren't there.

    For example, I'm currently struggling to use libkabc from C# so I can use the kontact name and addressbook.

    • Re:.NET (Score:1)

      by kko ( 472548 )
      At the office we're using a lot of .NET right now (most of the guys are using VB.NET, which I hate, but I'm going off on a tangent here...). We have a lot of old code and libs using C/C++, so I usually create wrappers using Managed C++. Interop is kinda weird (I don't think I really understand Interop), but the classes I create using Managed C++ usually work just fine.
      From what you're trying to do, I guess you are using Mono (am I right?). Isn't there some sort of Managed C++ for Mono? You might find it eas

    • Re:.NET (Score:4, Interesting)

      by DrSkwid ( 118965 ) on Monday November 10, 2003 @06:38AM (#7432944) Journal
      What you *really* need is a better way for libraries, and other code, to expose their functionality.

      Unix started down this road with 'everything is a file' but failed to follow through on that promise.

      When the Unix creators decided to take what they already knew and start again, 'everything is a file' became a design philosophy.

      Consequently, devices can be accessed through the file system [bell-labs.com]
      One can draw to a screen [bell-labs.com] via files, or open a internet network connection [bell-labs.com]

      The magic for all off this is a unified protocol 9p [bell-labs.com]. All file access is via 9p so if your program can speak 9p it can serve files to anyone. One binds a programs namespace into your own and off you go. The network becomes utterly transparent.

      In this way one waves bye bye to bindings and other marshalling techniques, who needs 'em.

      If your programming language can open and read and write files, it can do anything.

      It is just one of the many benefits that plan9 has brought to us.
      Too bad people are letting it slip past them.


      • If your programming language can open and read and write files, it can do anything.

        Forgive me and call me dense, I don't get it yet. Where does the philosophy of "everything is a file" buy you much over "everything is a network connection"?

        It still seems like there's a lot of work to be done in higher level layers on the raw interface so you can build things with more logic in them (think of odd beasts like SQL servers, SMTP, authentication servers, etc.). These "files" still behave differently and an a

        • You are correct in that as much as you need special code for dealing with what the files do as you would need special code to do other things.

          The point I was specifically addressing, binding's to the gui components, serves as a good example.

          The poster was crowing about .NET's "seamless bindings". Any .NET language can, apparently, have access to any of the available components. (I can't verify this but I imagine it pushes DCOM and the IDL a bit further). The problem for language writers is that the libra
      • You said it, but, people aren't to blame for letting it slip past them; the restrictions on its use make it non-Free Software, even though they've revised the license in the hopes of getting it taken up. I wonder though, even if it were to become fully open - would it even be possible to integrate it with Unix / Linux, or reimplement *nix as a subset? Ie, is there even a path for it to become mainstream, now?

        • Re: Plan 9 (Score:3, Interesting)

          by DrSkwid ( 118965 )
          It is true that the story of the license has hindered adoption of this interesting and intreaguing operating system. It serves as an illustration of how fraught with unseen circumstances the world is. Free software wasn't the way to go when plan9 was born 14 years ago. Lucent's Lawyers live in a different world. Bell-Labs has lost many of it's staff. It is a place where lightbulbs have been removed to save money.

          The user base, as monitored by newsgroup traffic, has been very slowly growing, a few more peop
    • .NET is a good framework, arguably better than the raw "Win32" API. But there is not much innovation in the languages themselves. XL and .NET are quite orthogonal.

  • 600 vs 800? (Score:3, Funny)

    by AtariAmarok ( 451306 ) on Sunday November 09, 2003 @09:18PM (#7431175)
    I've long wanted C++ to compile on my Atari 8-bit XL computer. At last, the moment has come!
  • That website smells an awful lot like, "Let's see how many buzzwords we can fit into as small a space as possible!"

    Of course, I didn't actually read any of it, so it could actually be damn cool. I'm personally of the opinion that we've yet to see a language that doesn't suck in one way or another...

    Maybe this is The One (tm) ... or have I been watching the Matrix a few too many times?
    • I've actually read it once. A long time ago. He seems to be going in the right direction. In my opinion, this is Stroustrups "much smaller and cleaner language struggling to get out" from C++.

      Getting it up to the production quality needed to compete with C++ is much more than a one-man task, though. And chances are it will die out like any other MFTL-project. But I would like to give him the benefit of doubt on this one.

      • >In my opinion, this is Stroustrups "much smaller and cleaner language struggling to get out" from C++.

        That's not what I see. It looks much more like an updated version of Ada to my eyes. Even the claims made are very similar to those made against C++ when Ada95 was new-fangeled and against C when Ada was born.
        • It looks much more like an updated version of Ada to my eyes. Even the claims made are very similar to those made against C++ when Ada95 was new-fangeled and against C when Ada was born.

          XL took from Ada a few ideas of syntax, those that I believed improved legibility. That's about it. What are the "claims" you are talking about?

          • I didn't mean that to be derogatory. It's just the whole, "Just as good as C++, but a clearer syntax, better abstractions, etc". I'm not saying it's wrong -- just that I've heard it before.
      • Getting it up to the production quality needed to compete with C++ is much more than a one-man task, though. And chances are it will die out like any other MFTL-project.

        ... Guess why I posted a story on Slashdot? Anybody interested in helping?

  • So exactly what is the language? (Score:3, Insightful)

    by grotgrot ( 451123 ) on Sunday November 09, 2003 @09:52PM (#7431352)
    The web site seems to completely lack examples. It also isn't apparent how they do 'objects' (ie bundles of data and the functions that operate on them). It just looks like a very poor man's version of Python to me.
    • 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 ;-)
      • Yes, but the only "object" example was a maximum concept. It is true that one test of a language is if you can write its own compiler in itself.

        My other test is what a Space Invaders program looks like. It would have to deal with drawing, responding to user input, timers etc.
    • It also isn't apparent how they do 'objects' (ie bundles of data and the functions that operate on them)

      The bootstrap compiler doesn't need objects, so it doesn't really implement them (and it's partially implemented in the old, non-boostrapped compiler). The language design has them. See http://mozart-dev.sourceforge.net/xl_features.htm, notably "Data inheritance", "Logical inheritance", "Function based dynamic dispatch".

    • The compiler source (which resembles neither C++, Lisp, nor XML) is on the website, but contains comments like this:
      // This document is confidential.

      // Do not redistribute without written permission
      Somehow I don't think this language is going to take off unless it is either opened up or adopted by a convicted monopolist.

  • hacker site!!! (Score:3, Funny)

    by Anonymous Coward on Sunday November 09, 2003 @09:59PM (#7431389)
    Whoa...check out that SWEET hacker logo in the upper right corner .. anybody else check it?

    That logo means this guy is a hacker (no, not the kind that break into computers illegally, the kind that have scrawny mustaches and like to shoot people with guns. Excuse me, like to shoot guns, not necessarily at people. But keep an eye on them anyway if you're a teacher or parent.)

    Wow, anybody kool enough to use the neat-o hacker logo must have like the most AWESOME program evarrrrr!

  • 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++.


    That's just silly. An APL version of it might be only 20 lines long, but it wouldn't be easier to work with because of that.
    • That's just silly. An APL version of it might be only 20 lines long, but it wouldn't be easier to work with because of that.

      It would also be possible to write it in one line in C++. A long line, though. However, if you actually look at the code by following the "Browse CVS" link on the web page, you will see that the XL code doesn't look anything like APL.

      I realize the limitations of LOC statistics. But I'm still happy to discover that, without any particular effort on my part, code written by the same

      • Since when has any normal language looked anything like APL? Nor -- even though I used to really like writing APL -- would I suggest it should.

        XL looks like a fairly nice language, frankly, but just being more concise isn't a recommendation.

  • A Quick Glance (Score:4, Interesting)

    by jefu ( 53450 ) on Sunday November 09, 2003 @10:30PM (#7431513) Homepage Journal
    A quick look at XL shows some interesting things to me. It has support for constrained genericity, programming by contract, the option of using indentation based block structuring or semicolons and end, what looks like a nicely structured rewriting capability that can be used to extend the language for supporting intentional programming, and a few other nice features.

    I did not see support for "iterators" mentioned directly, but if the extension mechanism is strong enough that should be doable.

    I'll be taking a careful look at it myself. These are some very powerful features. (Sather had many of these and was (in my experience) the best language I've ever used.) If C# had only put in decent syntax for some of these things I could have been persuaded that Microsoft was not the SAOE (Software Axis Of Evil), but they didn't.

    • Re:A Quick Glance (Score:3, Informative)

      by descubes ( 35093 )
      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).
      • Its hard to keep straight what the mozart project was aiming at and what the xl project is aiming at as the pages use almost identical kinds of layout and style.

        I would prefer iterators the way Sather did it though :

        loop
        i := 4.upto!(17) ; thats the iterator
        end ;

  • "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 la

    • Re:User Interfaces for programmers (Score:5, Informative)

      by descubes ( 35093 ) on Monday November 10, 2003 @05:33AM (#7432825) Homepage
      "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? ;-)

      • How does this differ from Beta? I've been interested in Beta for a long time, but I've not really seen the benefit of dynamically definable languages evident there - it just seems to go back to the lisp problem of writing, learning, and maintaining a special purpose language on top of a general purpose one. Any new programmer coming to the project is at an immediate disadvantage because of this.

        Asmo
        • How does this differ from Beta?

          I know very little about Beta, but the little I read indicates a very powerful language, but a not very accessible one.

          From a concept-programming point of view, it implements some elementary concepts in a noisy, distorted way. Take function calls as an example. I think it is important to have "A := 3" and "A(3)" be visibly different (regardless of whether you like the := syntax, for instance). From what I understand, both are written 3 -> A in Beta. This is artificial co

  • um... (Score:2)

    by pb ( 1020 )
    Has anyone else tried this, and actually gotten it to bootstrap?

    With gcc/g++: had to add in a #include <unistd.h> that was missing (needed it for sbrk()); compiled fine, bootstrap died with lots of errors. (it looks like it generates lots of bad C++ code or something)

    With icc: Compiled fine (modulo a few harmless warnings); bootstrap compile looks like it has hung (been going now for over 8 minutes!) -- but hey, at least it didn't die, right?

    I guess I'll take another look at this one when it isn't
    • Thanks for the unistd.h info. It's not needed on OSX, so I did not see it.
      Well, it looks like I need to do a new build pass on Linux ;-) Pre-alpha it is... But thanks for trying, and thanks for reporting.
    • With gcc/g++: ... compiled fine, bootstrap died with lots of errors. (it looks like it generates lots of bad C++ code or something)
      With icc: Compiled fine (modulo a few harmless warnings); bootstrap compile looks like it has hung (been going now for over 8 minutes!) -- but hey, at least it didn't die, right?

      I think both issues have been fixed. There were uninitialized values at a few places...

  • It looks more like an object oriented Pascal variant to me than the mentioned cross of C++, Lisp and XML. Have a look at the parser source [sourceforge.net].

    But it certainly looks like a nice, clean language, with lots of syntatic sugar removed: they seem to use parens only where absolutely necessary, no semicolons in sight and no curly braces anywhere... well, if you like sugar-free languages this one's for you :-)

    Luckily they seem to not follow the current trend of languages without header files, since I personally think

    • Re:Looks more like... (Score:3, Insightful)

      by descubes ( 35093 )
      The bootstrap compiler is limited. For instance, it doesn't have a 'switch' statement, or dynamic dispatch ("virtual functions" in C++ terms). The name lookup is very constrained by what the C++ back-end can do for me at low cost ;-) So overall, there is still a lot of verbosity and ugliness that is imposed by these limitations.

      Regarding header files, the compiler has an "import" statement. XL has modules, with separate files for module interface and module implementation. It's not fully functional in the

    • C++, Lisp, XML (Score:4, Interesting)

      by descubes ( 35093 ) on Monday November 10, 2003 @10:16AM (#7433684) Homepage
      than the mentioned cross of C++, Lisp and XML

      It's not in the looks. From http://xlr.sourceforge.net/info/xl.html:
      A lot of ideas come from older languages.

      • XL is a general purpose programming language.
        Think C/C++... without the syntactic and semantic complexity.
      • XL is a language with a simple, standardized program structure, for meta-programming
        Think Lisp... without the parentheses.
      • XL is a data language, not just a code language
        Think XML... with better support for highly structured data such as program.

      There are links to explanations on the original page.
      • XL is a language that uses indentation to define blocks.

        If you've read any of the stories about Python on /., you realize that this is a v. unpopular idea 'round here. I'm suprised that somebody hasn't started railing on XL for this yet.
    • It looks more like an object oriented Pascal

      Agree. The first thing that I thought of, looking at the source, was the unholy atrocity, sometimes referred to as Modula 5.

  • I'm very impressed by Concept Programming & XL. It appears to capture many ideas I have had about benefits and shortcomings of pattern matching, functional programming and object orientation.

    Could anyone point me to papers/books or PDF resources about this topic?
    • None that I know of. I think I invented this particular meaning of the terms "concept programming" (the same terms are used on the web to talk about different topics). I never found the time to actually write more than the web site itself. I'm more interested in hacking the compiler.
  • Where's the language manual?

  • XL? (Score:1)

    by pmz ( 462998 )

    It should have been named XXL, so I could make a mint selling sweatshirts to geeks.

  • The pain! The pain! (Score:1, Flamebait)

    by gooru ( 592512 )
    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?

    Ever heard of functional programming? That's the family of programming languages lisp is in? Ever programmed in them? They are freaking painful if you ask me. It makes so much more sense to use a procedural language in everyday progra

  • Nothing will ever get rid of C or C++. Java tried, C# tried, hell, D language [digitalmars.com] tried. When's the last time you heard of D?

    Oh, and if your next question is: why would we want to get rid of C... you're kidding, right?

  • The web site has background pictures below the text. That's the only thing I needed to know.

Slashdot Top Deals

"And remember: Evil will always prevail, because Good is dumb." -- Spaceballs

Close