MFELDMAN@GWUVM.BITNET (Mike Feldman) (09/22/87)
======================================================================== 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?
Kenneth.Lee@SEI.CMU.EDU (09/23/87)
> 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
jankok@cwi.nl (Jan Kok) (09/24/87)
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,