Re: Looking for volunteers for XL

"Christophe de Dinechin" <christophe@taodyne.com> wrote in message
> On Nov 27, 12:19 am, "BartC" <b...@freeuk.com> wrote:
>> Extensible languages have to be used with some care I think. Those
>> features aren't for everyday use.
>
> Apply your reasoning to libraries, and you'll see its limits. "It's
> not necessary to make available to the Unix programmer all those
> untidy function-building features".


Actually, heavy use of a library, especially a proprietary one, has
similar issues.


But at least it is usually obvious what is and what isn't a function
call; the name of the function should give a clue as to what it does,
and sometimes the module where it lives is provided also, useful extra
information.


And everyone understands about functions and knows the simple syntax
involved. Looking at sequence of unknown functions for the first time
won't faze anyone; but how about a long sequence of newly-invented
statements!


When extensibility is applied to syntax itself (for example), then
what will it look like? How will someone even know this is a new
syntax? Will there be keywords involved so that it can be looked up
somewhere, or is it just symbols? Can existing keywords be overloaded?
Can the same syntax mean something different depending on where it's
used?


Creating new functions is a bit like using jargon in English; you just
look the words up in a glossary. But new syntax is more like new
grammar.


The other kind of extensibility I know about is operator overloading,
where the problems are well-known; the expression A+B could
conceivably mean anything, instead of being restricted to a small set
of predefined types.


> I heard that exact reasoning from Basic gurus hearing about
> Pascal: "User-defined procedures? That can't be for everyday use.
> Who would need to add their own keywords? Leave that to Basic
> designers."


I never heard that, but the Basic guys were wrong. They would know
about subroutines, and could not really object to giving them proper
identifiers and having named parameters. And would know there could
potentially be thousands of the things in a large program.


But surely there is an upper limit to how many kinds of statements are
viable in a single language?


> notations suiting the ideas better. The objections that making a
> language extensible necessarily makes it unreadable or fragile flies
> in the face of our experience with other forms of abstractions, and
> even of the limited experience we have with those few languages that
> are actually extensible, such as most Lisp derivatives.


Well, I find Lisp unreadable anyway, without even knowing whether it is
over-using extensibility or not.


A self-extensible language sounds like a good idea and might well
work. I admit I've never used one (although I did play with designing
one once, then gave up), and have no idea what is and isn't possible;
could you create a language that has C syntax for example, then add in
a few Cobol-like statements or APL expressions? Or is the syntax it's
capable of rather more limited?


--
Bartc

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