Re: Looking for volunteers for XL

Christophe de Dinechin <>
Sat, 26 Nov 2011 12:38:04 -0800 (PST)

          From comp.compilers

Related articles
Looking for volunteers for XL (Christophe de Dinechin) (2011-11-22)
Re: Looking for volunteers for XL (Kaz Kylheku) (2011-11-26)
Re: Looking for volunteers for XL (Christophe de Dinechin) (2011-11-26)
Re: Looking for volunteers for XL (BartC) (2011-11-26)
Re: Looking for volunteers for XL (Christophe de Dinechin) (2011-11-27)
Re: Looking for volunteers for XL (BartC) (2011-11-27)
Re: Looking for volunteers for XL (Kaz Kylheku) (2011-11-28)
Re: Looking for volunteers for XL (Timothy Knox) (2011-11-27)
Re: Looking for volunteers for XL (BartC) (2011-11-28)
[13 later articles]
| List of all articles for this month |

From: Christophe de Dinechin <>
Newsgroups: comp.compilers
Date: Sat, 26 Nov 2011 12:38:04 -0800 (PST)
Organization: Compilers Central
References: 11-11-048
Keywords: design, comment
Posted-Date: 26 Nov 2011 16:25:29 EST

> [There were a bazillion extensible languages in the 1970s, many quite
> sophisticated. They all disappeared without a trace, largely because
> the ability to do per-program extensions meant that every program was
> written in a different language, making them all unreadable. It turned
> out that semantic extension, a la C++ overloaded operators, is a lot
> more usable than extra syntax. I assume you're familiar with EL/1,
> IMP-72, et al, so why is this any better? -John]

The first truly extensible language was Lisp, and it never
disappeared. It evolved, largely thanks to its extensible nature,
becoming the first language to get objects in a normalized way, for
example. This is the only language where normalization simply recorded
accepted extensions that had already been validated by its user base.
Contrast this with how C++ evolved by committee, adding features that
no one had really tried before (export templates anyone?) just because
it's so darn difficult to extend the compiler in the first place.

You expressed an opinion about why the languages you refer to failed,
which you do not substantiate. My personal opinion is that they
disappeared because they were too big and complex (for the time),
without bringing much value in return (at the time). That was back
when dedicating 50K to a compiler was considered luxury enough to be
mentioned in the manual for IMP-72 (see,173450), and
where there wasn't much need for more than one language anyway.

Things have changed. Making the language extensible no longer costs an
arm and a leg. And the vast majority of software projects today need
more than one language, when they do not simply go as far as using
meta-programming or DSLs. Whether you consider GUIs or distributed
programming, you always resort to some kind of meta-tools,
annotations, IDE, code generators, all sorts of things that
demonstrate a need to go beyond the base language.

Do these tools create dialects that are indecipherable to other users?
Well, yes and no.You need to learn about Qt's slots or about Doxygen
annotations, i.e. learn something above and beyond standard C++. But
that's not different from learning about Posix functions, the Java
class libraries or iOS. All these things are rather big "dialects",
you have to learn them before you can be fluent. We just manage.

As for why XL is better than these older languages: this is absolute
value in IMP-72

        <EXP> ::= ABS ( <A> ) ::= "A<0=>-A ELSE A"

Here is the same thing in XL:

        abs A -> if A < 0 then -A else A

This has much less "syntactic noise". In general, the older language
(not just extensible ones) had a rather complicated internal
representation. In XL, it's really simple, on a par with Lisp, but
enabling easy-to-read source code.

[I wrote actual programs in IMP-72. The compiler was slow, but not
unduly so for the time, and it was in the same ballpark as BLISS-11
which got a lot of use. (They both cross-compiled on a PDP-10.) We
gave up on it because we didn't want to try to remember which of six
slightly different case statements each program used. -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.