Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 19 Jun 2014 08:08:40 -0400, Peter Chapin wrote:

> On 2014-06-19 05:11, Dmitry A. Kazakov wrote:
> 
>>> Maybe it's a vocabulary issue, but it's not the part where tokens are
>>> carved out of input text that frighten me, but rather the first level of
>>> interpretation: what entity is that word referring to? More
>>> specifically, dealing with use clauses, prefix notations, overloading,
>>> and stuff like that.
>> 
>> That looks like sematic analysis to me, when you walk the AST finding
>> interpretations for each identifier there, prune matched interpretations
>> for type errors against competing signatures until there is single
>> interpretation for each, or none, or many conflicting. The most horrific
>> part is error messages generation. Which requires kind of mind-reading for
>> programmer's intention.
> 
> My understand is that parsing Ada requires name resolution to resolve
> syntactic ambiguities. This means symbol table management and dealing
> with Ada's visibility rules has to be done while parsing is taking place.
> 
> 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.
> I'm not sure right now but it is something I'll need to figure out soon.

You treat X.Y and X'Y as plain dyadic operators ("." and "'") and
identifiers leaving matching names to the semantics analysis. So, say,

   Ada.Finalization.Limited_Controlled'Class (X)

could become

   ("'" ("." (Ada, Finalization, Limited_Controlled), Class), X)

You need not to know any symbols at this stage, only a fixed set of
operators (".", "+", "-", "abs" etc).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de