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?

Comments

4500 vs. 2700?

[rekkanoryo]

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!

Re:4500 vs. 2700?

[CrypticSparrow]

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?

[Curien]

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?

[joto]

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.

Re:4500 vs. 2700?

[jilles]

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, ironically, require more loc for hello world). Java is a good example of less lines of code and more functionality compared to e.g. C.

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). The problem with this approach is that the internal representation is richer than the external. This information is typically lost when you exit the IDE or requires hacks like putting stuff in comments so the compiler can ignore it (e.g. GUI editors). Many of the concepts you work with in an IDE do not exist in first class representations at the source code level.

Because things need to be typed in manually, many programming languages are full of syntactic sugar which aim to reduce the amount of typing. For example the distinction between for and while is that for requires less typing than the equivalent while for some special cases of while. Neither captures the concept of iteration very well. In some languages this is addressed with more syntactic sugar.

Syntactic sugar is a poor replacement for proper abstractions. Intentional progamming may be a way out. However, I have yet to see a convincing and insightful example. So far all I see is variations of lisp.

Re:4500 vs. 2700?

[descubes]

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

XL?

[Ricwot]

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?

[egrinake]

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

-- Alan Perils

:)

600 vs 800?

[AtariAmarok]

I've long wanted C++ to compile on my Atari 8-bit XL computer. At last, the moment has come!

So exactly what is the language?

[grotgrot]

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.

Re:So exactly what is the language?

[descubes]

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 ;-)

hacker site!!!

[Anonymous Coward]

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!

A Quick Glance

[jefu]

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

[descubes]

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).

User Interfaces for programmers

[ezy]

"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...

Re:User Interfaces for programmers

[descubes]

"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? ;-)

Re:Looks more like...

[descubes]

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 boostrap compiler (for instance, the body is actually visible to the caller...)

Re:.NET

[DrSkwid]

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
One can draw to a screen via files, or open a internet network connection

The magic for all off this is a unified protocol 9p. 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.

C++, Lisp, XML

[descubes]

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.

Re: Plan 9

[DrSkwid]

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 people at a time but nothing like a swell. Catch22 : more users = more momentum for change in whatever direction.

There is no-one officially paid to maintain plan9 any more, though it still is under active maintenance.

It won't die for a good while yet, it is a nice antithesis of eye candy & gee whizzery replaced by real magic.