Re: Strange syntax

Re: Strange syntax

[Kenneth.Lee]

> From: "GBURG::CWILLIAMS" <cwilliams%gburg decnet@bluto scc com>
> The Rational R1000 compiler also accepts the example as legal and does execute
> properly. Given the fact that DEC-Ada also accepts it, I would say that it is
> in fact legal Ada. The fact that other compilers reject it as erroneous 
> suggests to me that the example should be added to the ACVC if the final 
> determination is that the example is legal.
> 
> Chuck Williams
> CONTEL Federal Systems

The Rational R1000 compiles the code because the first step when a source
unit is promoted to an installed unit is to format the code.  The
reformatted code for the line in question is:
	Foo : Integer range 1 .. Max_Val + 1 := 15;

The following, recent post on the SEI bboard from Robert Firth provides an
explanation for the compiler diagnostics.

22-Sep-87 17:52    Robert Firth@sei cmu edu     1:= syntax error
The problems with "1:=" generating an error can be traced to
[RM 2.4.2 - Based Literals] and [RM 2.10 - Allowable Replacements of
Characters].

The compiler believes that the sequence "1:" introduces a based literal,
for instance "1:0123:".  Accordingly, it fails on the "=" character,
which cannot be part of a based literal.

Recall that, while based literals are usually written "2#1010#", the
colon is an allowable replacement for the hachure.  You should expect
various error messages, such as "illegal char in based literal",
"invalid base in based literal", and so on.

This lexis is correct according to the RM - indeed, any alternative
would no longer be LR(1) and so would cause trouble for automatic
scanner generators.  And the colon is a replacement character because
Steelman required that Ada be representable using a 56-character set.

Sigh.

Robert


-----


Ken

Re: Strange syntax

[Jan Kok]

In article <8709231753.AA26614@q.sei.cmu.edu> Kenneth.Lee@SEI.CMU.EDU writes:
>
>The Rational R1000 compiles the code because the first step when a source
>unit is promoted to an installed unit is to format the code.  The
>reformatted code for the line in question is:
>	Foo : Integer range 1 .. Max_Val + 1 := 15;
>
> ...
Well, this is not an explanation of course. It only says that there is a
reformatter that solves correctly the ambiguity with the ':'.
I wish to contribute to the discussion (the example is correct Ada) that
the colon is not the only ambiguous character where the difficulties have
been overlooked by some of the compiler writers. And apparently also by
the composers of the ACV suite, since we are talking avout validated
compilers.

Period, prime, quotation mark and minus may be used to construct other
teasers. A try:

   PUT(A.all'FIRST);

   PUT(B.all(1)'LAST);

   C := B--- comment
   - D; -- or
   C := B--- comment
   D;

   procedure TT is
     function "*"(A, B:INTEGER) return INTEGER is
       subtype INT is INTEGER;
       C :"*".INT:=3;
       D :TT."*".INT:=4;
       E:SYSTEM.ADDRESS:= TT."*"'ADDRESS;
       -- with these declarations, the following example has been on the
       -- net recently:
       procedure WRITE ( X:"*".INT) is
       begin null; -- or something
       end;
     begin C:="*".INT'LAST;
       return (A*"*".INT'(B));
     end"*";
   begin null; end TT;

But who should write real life code like this? :-)
    Jan Kok.
-- 
Mail: Jan Kok, CWI (afd. NW), Postbus 4079, NL-1009 AB Amsterdam, Nederland
Net : jankok@cwi.nl
               It was twenty years ago today,
               Sgt. Pepper taught the band to play,

strange syntax

[Mike Feldman]

========================================================================
Dave Emery writes:


>Here's a real ada-guru question:
>Is the following program (syntactically) legal?
>  package demo is
>    max_val : constant := 15;
>    -- check the next declaration out carefully...
>   foo : integer range 1 .. max_val +1:= 15;
>   -- some compilers complain right  ^ there, and say that 1: is not
>   -- a legal literal, and then i get all kind of errors...
> end demo;
>It's obvious from reading the program what is meant, but must a
>parser be able to determine that +1: breaks down to 3 tokens, "+", "1"
>and ":="?


This looks really quirky to me. I tried it with four compilers: Meridian
1.5, Ada/Ed-PC, TeleSoft 3.1.3 VMS and Verdix 5.4.1 Sun. _All_ rejected
the program, typically with some "bad literal" message, with or without
further propagation. Oddly enough, _all_ accepted the program if a
blank was put after the 1 but before the colon! (i.e. +1 := ).

I cannot imagine a context for : in that position that's not going to
be a := - are there any syntax buffs out there who can explain just what
is ambiguous in that context?