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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,1be1b347b5b5ad43
X-Google-Attributes: gid103376,public
From: "Robert I. Eachus" <eachus@mitre.org>
Subject: Re: Ayacc/Aflex "entropy" (P2Ada)
Date: 1999/10/29
Message-ID: <3819CBDA.E801A064@mitre.org>#1/1
X-Deja-AN: 542111794
Content-Transfer-Encoding: 7bit
References: <3813716C.52655126@Maths.UniNe.CH> <7v2400$e02$1@nnrp1.deja.com>
 <7v30jd$3i6$1@nnrp1.deja.com> <7v3u0f$nn6$1@nnrp1.deja.com>
 <3816331A.99C596D2@mitre.org> <7v5ns8$2h1$1@nnrp1.deja.com>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: usenet@news.mitre.org
X-Trace: top.mitre.org 941214349 10583 129.83.41.77 (29 Oct 1999 16:25:49 GMT)
Organization: The MITRE Corporation
Mime-Version: 1.0
NNTP-Posting-Date: 29 Oct 1999 16:25:49 GMT
Newsgroups: comp.lang.ada
Date: 1999-10-29T16:25:49+00:00
List-Id: <comp.lang.ada>



Robert Dewar wrote:
> 
  
> I think the parsing algorithm is less of an issue than error
> recovery,...

   Ageed.

> ...the error recovery of YACC is pathetic.

   Worse than that.  Since YACC does not even correctly implement
LALR(1),
you sometimes have to work hard to get it to compile correct programs.

> It is
> surprising what can be done with automatic generators in
> this area. See some of the papers from Fisher and Charles from
> the early days of the NYU Ada/Ed project.

  Yep, very good, and as you may remember Pat Prange and I extended LALR
on Multics in this direction.

> Many commercial Ada/83
> compilers made use of this work, and the syntactic error
> recovery of Ada/Ed was really quite good (not as good as GNAT,
> but GNAT has a lot of careful hand coded heuristic stuff that
> I doubt any automatic system could fully match).
 
   Agreed.  Again when using LALR, the automatic error messages and
error recovery was acceptable, but adding just a few 'extra' productions
to the grammar can (and did) vastly improve error diagnosis.  In fact,
one of the hardest problems of generating meaningful error messages is
knowing what the user intended to do, or for that matter what users do
wrong.  One of the biggest advantages of the Open Source approach is
that it is easier to get feedback on unacceptable error diagnostics. 
For example:

   ...
   package body Foobar is
   ...
   procedure Foo(X: in out Bar);
     I: Integer :=3;
   begin ...

   Is syntactically correct in Ada, but cannot be correct semantically.
However there is no semantic rule that says it is illegal either. 
Putting in a special case rule to recognize that the semicolon should be
an "is" helps a lot, but you also want to look further to deliver the
right error message.  This error commonly happens when someone uses the
package specification as a template for creating the package body.  But
does that begin belong to Foo or Foobar?  Looking at the package 
specification helps, but you really need to look ahead to see the "end"
that matches it.  (And of course insert a dummy body or change the
semicolon to "is" as appropriate.)

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...