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

Christian Fabre <fabre@gr.osf.org>
23 Feb 1996 18:21:42 -0500

          From comp.compilers

Related articles
[3 earlier articles]
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)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) anton@complang.tuwien.ac.at (1996-02-27)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) blume@zayin.cs.princeton.edu (1996-02-27)
[11 later articles]
| List of all articles for this month |

From: Christian Fabre <fabre@gr.osf.org>
Newsgroups: comp.compilers
Date: 23 Feb 1996 18:21:42 -0500
Organization: OSF-RI Grenoble, France.
References: 96-01-037 96-02-187 96-02-226
Keywords: standards

Ronald F. Guilmette 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
> to insist that language standardization committees write complete
> FORMAL SPECIFICATIONS for the arcane and baroque languages that they
> are trying to standardize. If we (the consumers) did this, you would
> quickly see the wheat being separated from the chaf, and large numbers
> of overly complex features being tossed overboard (like so much
> ballast), much to the benefit of the average programmer-on-the-street
> who has to code in these unfortunate and massively over-engineered
> travesties of programming languages that we have today.


I really second the requirement of Formal Specifications, despites the
fact that I am far from being an expert in the field of FS.


DDC-I (Denmark) have developped formal specification of the ANDF
language within the GLUE project. I have found them very usefull and
_*very*_ (enough emphasis?) clear to read, despites the fact that they
are 990 pages long compared to the 50/60 pages of the plain english
specs. It is a shame people give up because of the thickness of the
FS.


The Static part was the most complicated part IMHO, at least when I
tried to read it linearly. So I jumped directly into the Dynamic
Semantics of some constructs that I wanted to read, and when back to
the SS only when I needed to clarify something. This has proven to be
very effective.


I have found the DS part very usefull to question small oddities in
the specifications of the ANDF language: "This should be simple, why
do we need 20 lines for that?"


The Dynamic Semantics is using the formalism of Action Semantics (AS)
(http://www.brics.dk/users/thales/as/AS.html) developped by Pr
P.D.Mosses from the Univesity of Aarhus, Denmark. As I said, I am not
an expert in the field of FS, but this formalism is very neat and had
sound basis to specify tricky things such as exception handling. It is
compact indeed, as they have an example of Pascal FS taking something
like 20 or 40 pages...




> How thick will the COBOL standard of the year 2015 be? Five
> thousand pages? Ten thousand? More?


This is scary. It took me a while to get confident in ANSI-C, and its
oddities (promotion lattice, various meanings of volatile etc), and
the standard is just 220 pages long...


Our moderator note:


> [Formal defs may help, but having attempted to make sense of the PL/I
> standard, I can't see them as a solution to bloat. The Cobol crowd at
> least divides their language into sublanguages that you can understand
> and add to your implementation one at a time. -John]


How long ago was the PL/I FS writen?


I would guess before 1990. This is 1996 now, and just as any other
field of computer science, the FS field is making progress.


Ch.


=====
      Christian Fabre ANDF: http://www.osf.org/andf
OSF Research Institute Net: fabre@gr.osf.org
    2 avenue de Vignate Tel: +33 76.63.48.90
  38610 Gieres - France Fax: +33 76.51.05.32
--


Post a followup to this message

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