From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,3a1c64628a09855b
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Fri, 11 Apr 2008 19:27:17 +0200
From: Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de>
Reply-To: rm.tsoh+bauhaus@maps.futureapps.de
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Lack of formal syntax undermines Ada
References: 
 <e99fb94d-da10-41d2-9f20-7a6ce78d4613@p25g2000hsf.googlegroups.com>
In-Reply-To: 
 <e99fb94d-da10-41d2-9f20-7a6ce78d4613@p25g2000hsf.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <47ff9f76$0$4848$9b4e6d93@newsspool4.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 11 Apr 2008 19:27:18 CEST
NNTP-Posting-Host: 7926c1a1.newsspool4.arcor-online.net
X-Trace: 
 DXC=;\O=M6THa4\[7Non7UCi8U4IUK<Cl32<Q4Fo<]lROoRQ^;5]aA^R6>R]=k9UO18@B\PCY\c7>ejVXKoE9cE1F;LZaL[0lKR]nDW
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:20881
Date: 2008-04-11T19:27:18+02:00
List-Id: <comp.lang.ada>

usenet@leapheap.co.uk wrote:

> Ada is designed for the construction of high-integrity software
> by validated compilers. Would it not be better to have formal
> Ada lexical and syntactic rules, expressed in regular expression
> and BNF format respectively, even if such rules turn out to be
> not particularly readable?

How will a syntax that is simple for the parser writer cause
the language to be the best one for the programmer?
In fact Ada was reportedly not designed to make the tool writers
life easier.

Some of the ambiguity might in part have been caused by
an original requirement,
http://archive.adaic.com/docs/reports/steelman/steelman.htm#2
but I can't tell. Actually, there have been arguments in favor
of "overloaded parentheses" here because they permit switching
between array access and function call without notice.