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.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: border1.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!border2.nntp.dca3.giganews.com!backlog4.nntp.dca3.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!ottix-news.ottix.net!newsswitch.lcs.mit.edu!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! Date: Thu, 19 Jun 2014 17:13:19 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1402308235.2520.153.camel@pascal.home.net> <85ioo9yukk.fsf@stephe-leake.org> <255b51cd-b23f-4413-805a-9fea3c70d8b2@googlegroups.com> <5ebe316d-cd84-40fb-a983-9f953f205fef@googlegroups.com> <2100734262424129975.133931laguest-archeia.com@nntp.aioe.org> <857442918424729589.090275laguest-archeia.com@nntp.aioe.org> <9j4b774g2gbz$.a22j8j4ai1l1$.dlg@40tude.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls7.std.com 1403212378 10004 192.74.137.71 (19 Jun 2014 21:12:58 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 19 Jun 2014 21:12:58 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:2erPqWSeXEPzl1xKi4ABkxqD3U0= X-Original-Bytes: 4478 Xref: number.nntp.dca.giganews.com comp.lang.ada:187078 Date: 2014-06-19T17:13:19-04:00 List-Id: Peter Chapin writes: > My understand is that parsing Ada requires name resolution to resolve > syntactic ambiguities. Yes. The syntax rules given in the RM are ambiguous. For example, in a context expecting an expression, "X(Y)" could be a function_call, type_conversion, indexed_component, or slice. (Did I forget any?) Likewise, in statement context, that same text could be a procedure_call or an entry_call. The "X" in "X.Y" could be a name or an implicit_dereference. But... >...This means symbol table management and dealing > with Ada's visibility rules has to be done while parsing is taking place. But no, it doesn't mean that, and in fact mixing semantic analysis with parsing is highly undesirable. The parser should build a tree, and not any "symbol table" kinds of things. The output of the parser should depend ONLY on the contents of a single source file; it shouldn't need to know about separate compilation. Semantic analysis then walks the tree built by the parser. The way to deal with an expression "X(Y)" is for the parser to build a tree node that represents "something that looks like a call or a type_conv or ...". That is, "a name followed by a parenthesized, comma-separated sequence of expressions". That has been called an "Apply" node in some compilers. Basically, you need to write a grammar for Ada that is unambiguous, and that allows a superset of what the RM grammar allows. When semantic analysis sees an Apply node for X(Y), it looks up X and Y. It might find X denotes a type, or denotes one or more functions, or .... I've done serious work on about 7 or 8 Ada compilers, and this is how ALL of them worked. (Here, I'm counting independently designed compiler front ends, not different host/target platforms. That is, GNAT counts as "1 Ada Compiler" I've worked on, even though it supports many platforms.) > This probably depends on precisely how one goes about the parse. Perhaps > it is possible to live with the ambiguity and generate a useful parse > tree anyway, deferring the rest of the analysis until later, as you say. Yes, I think that's what I was saying above. C compilers typically work the other way (mixing parsing with semantic analysis), to solve syntactic ambiguities related to "typedef". IMHO any language that forces that design on a compiler is broken. I'm not sure C forces that design; maybe the typedef problem could be solved differently, but it doesn't look easy to me. > I'm not sure right now but it is something I'll need to figure out soon. - Bob