Re: Interesting article on ARG work

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

On 09/04/2018 22:24, Randy Brukardt wrote:
> Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:pag4fd$pn4$1@gioia.aioe.org...
>> On 2018-04-09 18:12, Niklas Holsti wrote:
>>
>>> For example, the text
>>>
>>>   if Foo then
>>>   Bar;
>>> @ else
>>> @ Baz;
>>>   end if;
>>>
>>> would be parsed in four ways, according to the four combinations of
>>> choices (enabled/disabled) for the two @ signs:
>>
>> [...]
>>
>> It is a trivial recursive-descent parser. "else" cannot follow "@",
>> because there is no statement starting with "else". Full stop.
> 
> Of course, that would very much emasulate the feature (probably 25% of the
> @-code in Janus/Ada is to remove various "elsif" and "else" cases).
> [Remember, we designed this code to work on very small memory hosts, so
> anything not critical to the operation of the compiler is removed. One
> reason that I don't use that any more in production code.]
> 
> Another common use that you wouldn't allow is to remove the exception
> handler from some code. (For Janus/Ada, the existence of an exception
> handler has a cost, so if it is not needed for production code, it is best
> completely eliminated.)

I think both cases would be happily handled by optimization:

    if ... then
      ...
    else
      @ Something
    end if;

Since @ Something becomes null, else null; is removed by the optimizer. 
The same would happen with

    exception
       when ... =>
          @ Something
          [raise;]

> I think you could come up with a rule that would be less harmful to the
> feature than requiring full statements, especially for composite statements
> like if and case and blocks.

Maybe, but that would require more pages to explain in the RM (:-))

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