Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C)

Dave Lloyd <dave@occl-cam.demon.co.uk>
22 Feb 1996 00:40:10 -0500

          From comp.compilers

Related articles
Possible to write compiler to Java VM? (I volunteer to summarize) seibel@sirius.com (Peter Seibel) (1996-01-17)
Re: Aliasing in ISO C jplevyak@violet-femmes.cs.uiuc.edu (1996-02-16)
Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) rfg@monkeys.com (1996-02-19)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) jgm@CS.Cornell.EDU (1996-02-19)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) Martin.Jourdan@inria.fr (1996-02-21)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) robison@kai.com (Arch Robison) (1996-02-21)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) hbaker@netcom.com (1996-02-22)
Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) dave@occl-cam.demon.co.uk (Dave Lloyd) (1996-02-22)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) gasser@ilw.agrl.ethz.ch (Laurent GASSER) (1996-02-23)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) fabre@gr.osf.org (Christian Fabre) (1996-02-23)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) WStreett@shell.monmouth.com (1996-02-23)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) hbaker@netcom.com (1996-02-23)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) k2consult@aol.com (1996-02-26)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) henry@zoo.toronto.edu (Henry Spencer) (1996-02-27)
[13 later articles]
| List of all articles for this month |

From: Dave Lloyd <dave@occl-cam.demon.co.uk>
Newsgroups: comp.compilers
Date: 22 Feb 1996 00:40:10 -0500
Organization: Compilers Central
References: 96-01-037 96-02-187 96-02-226
Keywords: C, standards, design

Ronald F. Guilmette <rfg@monkeys.com> wrote:
> I see only one solution. We must at some point introduce some
> disipline into the process of crafting languages and their standards.
> There is one good way to do that which would also result in the
> languages themselves being not only smaller, but less buggy. We need


Well we started down this path with ALGOL 60 which gave us all
BNF. Throughout the 60s the manner of specification was refined, and
Algol 68 was defined with a two-level grammer (still known in many
quarters as Wijngaarden grammers) that very succinctly defined the
syntax with context. A mathematic English was used to define the
semantics of the language. Much was proved about the language
(including a minor mistake or two which were fixed in the 1973
revision). The 1973 Report on Algol 68 is 200 (A5) pages including
examples and full descriptions of the standard prelude (the raw
language stops on p122) and defines more comprehensively a language
far larger than Ansi C in far less verbiage. Since then language
definition has progressed, but in the 'backwaters'. Denotation
semantics has come along with the formal specification languages. We
really are *capable* of doing a good job of language design. We have
the tools.


However this was the 'academic' family of languages. Meanwhile lots of
ad-hoc languages grew up (the worst of which being of course C). The
modern form of language definition against which the poster complains
is the 'industrial' family: Fortran-90, Ansi C, C++, Ada, Cobol,
etc. These seem to be wilfully neglecting the science of designing
programming languages, in favour of large committees of competitive
vendors driven by the desire to please customers - what the customer
wants is what the customer gets seems to be the order of the day on
ALL of these committees (see the discussion on GC if you doubt me).
And so what each customer gets is an inconsistent hodge-podge of all
the other customers' ideas, filtered by some fool bright-spark in the
compiler company (myself included) and then voted on in committee in
isolation (I could not believe this in my first encounter with a
language committee, surely a language has to be considered as a
whole!).


Gregory Morrisett <jgm@CS.Cornell.EDU> wrote:
> Providing a precise semantics for a language is not just something
> for the "theoriticians" to do -- it really provides the basis for
> a language -- a contract for both the implementors and the users.
> Without one, the language is meaningless (pun intended).


This really is the key point. If you can't understand the contract,
what are you doing signing on the line?


----------------------------------------------------------------------
Dave Lloyd Email: Dave@occl-cam.demon.co.uk
Oxford and Cambridge Compilers Ltd Phone: (44) 1223 572074
55 Brampton Rd, Cambridge CB1 3HJ, UK
--


Post a followup to this message

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