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

Henry Spencer <henry@zoo.toronto.edu>
1 Mar 1996 14:07:04 -0500

          From comp.compilers

Related articles
[11 earlier articles]
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)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) przemek@rrdjazz.nist.gov (1996-03-01)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) dave@occl-cam.demon.co.uk (Dave Lloyd) (1996-03-01)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) dave@occl-cam.demon.co.uk (Dave Lloyd) (1996-03-01)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) henry@zoo.toronto.edu (Henry Spencer) (1996-03-01)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) WStreett@shell.monmouth.com (1996-03-03)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) jens.hansson@mailbox.swipnet.se (1996-03-06)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) jens.hansson@mailbox.swipnet.se (1996-03-08)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) rfg@monkeys.com (1996-03-10)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) jan@neuroinformatik.ruhr-uni-bochum.de (1996-03-11)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) (1996-03-12)
[1 later articles]
| List of all articles for this month |

From: Henry Spencer <henry@zoo.toronto.edu>
Newsgroups: comp.compilers
Date: 1 Mar 1996 14:07:04 -0500
Organization: SP Systems, Toronto
References: 96-02-234 96-02-308 96-02-326
Keywords: standards, C

  ...This is why the ANSI C committee deliberately decided against formal
  specifications. The fact that much of the audience for the contract
  cannot read formal specs is regrettable, but it is a fact and it
  will not change any time soon.


blume@zayin.cs.princeton.edu (Matthias Blume) writes:
>It is also a fact that the same audience is unable to understand the
>ANSI C specification...


Actually, *most* of them can understand *most* of it quite well. Fine
points can require consulting a language expert, but that's true of
any form of language description; there is no way around the fact that
such specs are substantial documents and some questions require
knowing the whole spec intimately. However, there is a large payoff
for even limited understanding: not only does it make it possible for
non-experts to answer simple questions themselves (*usually*
correctly), it also makes it easier for them to gradually deepen their
understanding until they stop needing experts.


In this and similar matters, there is a school of thought which claims
that only experts should get involved, that if you aren't up to being
an expert, you should consult one rather than trying to solve your
problem yourself. While there is some merit in this view, it also
ignores reality: experts are in short supply, and many people need to
get results without having the time to become experts or the money to
consult existing experts, even if this does mean some risk of
mistakes.


Languages whose definitions are accessible only to experts are likely
to remain the obscure playthings of tiny communities of experts.


>...I venture to say that everybody who can read and FULLY
>understand all of the definition of ANSI C will also be able to
>understand "The Definition of Standard ML", (perhaps after a short
>introduction to the notation used...


Quite possibly true. However, such people are a small minority of
those who can read, and benefit from reading, the ANSI C definition.
--
Henry Spencer, henry@zoo.toronto.edu
--


Post a followup to this message

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