Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!hpda!hplabs!decwrl!labrea!rutgers!im4u!ut-sally!utah-cs!defun!shebs
From: shebs%defun.uucp@utah-cs.UUCP (Stanley T. Shebs)
Newsgroups: comp.software-eng
Subject: Re: Software Technology is NOT Primitive
Message-ID: <5092@utah-cs.UUCP>
Date: Fri, 30-Oct-87 18:09:46 EST
Article-I.D.: utah-cs.5092
Posted: Fri Oct 30 18:09:46 1987
Date-Received: Thu, 5-Nov-87 04:32:51 EST
References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <3603@sol.ARPA> <326@moncsbruce.oz>
Sender: news@utah-cs.UUCP
Reply-To: shebs%defun.UUCP@utah-cs.UUCP (Stanley T. Shebs)
Organization: PASS Research Group
Lines: 42

In article <326@moncsbruce.oz> conybear@moncsbruce.oz (Roland Conybeare) writes:

>	I feel that many modern computer languages suffer from *hubris* on the part
>of the language designer(s).  Like everybody, language designers make mistakes,
>and I have yet to see a 'perfect' language.  I do not expect the 
>designer to anticipate all the features I might want in their language.  I
>do mind when the designer says "take my language and submit to it's rules,
>or write in assembler".

Of course, everyone is free to design their own languages.  It's also the
case that programmers are free to use whatever language is available, unless
they are working in some kind of preexisting and restrictive context (DoD,
maintenance of old code, etc).  Making the language implementation available
is just a matter of programming, using well-known techniques.  Therefore,
any moaning and complaining about languages must issue from people who are
unwilling to do the work themselves, and who think that there is a whole crowd
of language specialists who have nothing better to do, and must be coerced
into thinking the "right" way.

There's nothing to stop anyone from introducing a new and wildly popular
language, and I say to them: go for it!

>	I also propose that our compilers should be extensible.  My ideal compiler
>would look like one of today's compilers, but decomposed into a set of modules,
>with explicit interfaces.  Some modules would describe how to compile builtin
>types.  If I did not like the compiler's code generation for floating point
>numbers,  I could reimplement the appropriate module.  [...]

This is a very good idea, and can be found in the latest Lisp compilers.
Unfortunately, it's tricky to use, and not documented very well.  There is
still a lot of theory needed to get a certain level of generality;  without
that basis, users would moan and complain about all the restrictions placed
on extensions to the compiler.  For instance, getting register allocation to
work correctly in the presence of user-supplied assembly code is tricky...
Look for some amazing compilers in about 10-20 years, maybe less if the work
ever gets funded adequately.  (Compilers are not a fashionable topic at the
moment, sigh.)

>Roland Conybeare

							stan shebs
							shebs@cs.utah.edu