'raise' in aspects?

'raise' in aspects?

[Stephen Leake]

The Ada mode 5.0 parser rejects this code:

   subtype Integer_String is String
     with Dynamic_Predicate => Integer'Value (Integer_String) in Integer
            or else raise Constraint_Error with "not an integer string";

It complains that 'raise' is not allowed here.

ALRM Annex P says the syntax for an aspect is:

     aspect_specification ::= 
        with aspect_mark [=> aspect_definition] {,
                aspect_mark [=> aspect_definition] }

     aspect_mark ::= aspect_identifier['Class]

     aspect_definition ::= name | expression | identifier


And you can't put 'raise' in an expression, which is why the Ada mode
parser rejects it.

But GNAT GPL 2014 accepts it.

Maybe this is from an AI?

Randy says the next Ada version is described in
http://www.ada-auth.org/standards/2xrm/html/RM-13-1-1.html

But that gives the same 'expression' syntax for this.

Hmm; it does add:

36/3
 Alternative legality and semantics rules may apply for particular
 aspects, as specified elsewhere in this International Standard.

(that should be 36/4? 2012 is /3; this is new in 202x. or maybe it's
just a clarificaton of 2012?)

Searching that LRM for Dynamic_Predicate didn't turn up anything about
'raise' in aspects.

There was a recent discussion on comp.lang.ada about the new aspect
Predicate_Failure, and implied that 'raise' was allowed in aspectes,
since the code discussed had that. Predicate_Failure is in the 202x
manual, but it still doesn't give a syntax that allows 'raise'.

Can anyone point me to RM language that allows 'raise' in aspects?

Or maybe this is a GNAT extension? I don't see anything in the GNAT
reference manual about it, but I'm not sure I know where to look.

-- 
-- Stephe

Re: 'raise' in aspects?

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> And you can't put 'raise' in an expression, which is why the Ada mode
> parser rejects it.

This is AI12-00221[1].

The relevant ARM section is 4.4(3)[2].

[1]
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0022-1.txt?rev=1.13
[2] http://www.ada-auth.org/standards/2xrm/html/RM-4-4.html#p3

Re: 'raise' in aspects?

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> And you can't put 'raise' in an expression, which is why the Ada mode
>> parser rejects it.
>
> This is AI12-00221[1].
>
> The relevant ARM section is 4.4(3)[2].
>
> [1]
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0022-1.txt?rev=1.13
> [2] http://www.ada-auth.org/standards/2xrm/html/RM-4-4.html#p3

This code doesn't format with the latest ada-mode from mtn, but it does
raise the exception:

$ ./validity 

raised CONSTRAINT_ERROR : not an acceptable string

   with Ada.Text_IO;
   procedure Validity is

      S : String := "43";

      B : Boolean := Integer'Value (S) in 1 .. 42
      or else raise Constraint_Error with "not an acceptable string";

   begin
      Ada.Text_IO.Put_Line (B'Img);
   end Validity;

Re: 'raise' in aspects?

[Stephen Leake]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> The Ada mode 5.0 parser rejects this code:
>
>    subtype Integer_String is String
>      with Dynamic_Predicate => Integer'Value (Integer_String) in Integer
>             or else raise Constraint_Error with "not an integer string";
>
> It complains that 'raise' is not allowed here.
>
> ALRM Annex P says the syntax for an aspect is:
>
>      aspect_specification ::= 
>         with aspect_mark [=> aspect_definition] {,
>                 aspect_mark [=> aspect_definition] }
>
>      aspect_mark ::= aspect_identifier['Class]
>
>      aspect_definition ::= name | expression | identifier
>
>
> And you can't put 'raise' in an expression, which is why the Ada mode
> parser rejects it.
>
> But GNAT GPL 2014 accepts it.
>
> Can anyone point me to RM language that allows 'raise' in aspects?

For the record:

ai12-0022 adds "raise_expression" to the "relation" syntax. It's a
binding interpretation on Ada 2012

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0022-1.txt?rev=1.13

-- 
-- Stephe

Re: 'raise' in aspects?

[Randy Brukardt]

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
news:85h9ywasfq.fsf@stephe-leake.org...
> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> The Ada mode 5.0 parser rejects this code:
>>
>>    subtype Integer_String is String
>>      with Dynamic_Predicate => Integer'Value (Integer_String) in Integer
>>             or else raise Constraint_Error with "not an integer string";
>>
>> It complains that 'raise' is not allowed here.
>>
>> ALRM Annex P says the syntax for an aspect is:
>>
>>      aspect_specification ::=
>>         with aspect_mark [=> aspect_definition] {,
>>                 aspect_mark [=> aspect_definition] }
>>
>>      aspect_mark ::= aspect_identifier['Class]
>>
>>      aspect_definition ::= name | expression | identifier
>>
>>
>> And you can't put 'raise' in an expression, which is why the Ada mode
>> parser rejects it.
>>
>> But GNAT GPL 2014 accepts it.
>>
>> Can anyone point me to RM language that allows 'raise' in aspects?
>
> For the record:
>
> ai12-0022 adds "raise_expression" to the "relation" syntax. It's a
> binding interpretation on Ada 2012
>
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0022-1.txt?rev=1.13

Right, "raise_expression" can be used in any expression, not just aspects. 
Indeed, we immediately noticed that it fixed one long-standing problem in 
Ada (the need to have a return statement in every function). You can write
    raise Program_Error with "Not yet implemented";
in any function (since a raise expression matches any type), and you don't 
have to dream up a useless dummy return value to do so.

                                     Randy.

Re: 'raise' in aspects?

[Shark8]

On 10/23/2014 4:42 PM, Randy Brukardt wrote:
> Indeed, we immediately noticed that it fixed one long-standing problem in
> Ada (the need to have a return statement in every function). You can write
>      raise Program_Error with "Not yet implemented";
> in any function (since a raise expression matches any type), and you don't
> have to dream up a useless dummy return value to do so.

That is nice!
(I didn't realize they were actually so generalized.)

Re: 'raise' in aspects?

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> You can write
>     raise Program_Error with "Not yet implemented";
> in any function (since a raise expression matches any type), and you don't 
> have to dream up a useless dummy return value to do so.

actually

   return raise Program_Error with "Not yet implemented";

of course.

I liked (but haven't had reason to try; I had already spent far too long
generating "useless dummy return values") Bob Duff's recursive solution:

   function F return Boolean is
   begin
      raise Program_Error with "Not yet implemented";
      return F;
   end F;

Re: 'raise' in aspects?

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyy4s67x3m.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> You can write
>>     raise Program_Error with "Not yet implemented";
>> in any function (since a raise expression matches any type), and you 
>> don't
>> have to dream up a useless dummy return value to do so.
>
> actually
>
>   return raise Program_Error with "Not yet implemented";
>
> of course.

Right.

> I liked (but haven't had reason to try; I had already spent far too long
> generating "useless dummy return values") Bob Duff's recursive solution:
>
>   function F return Boolean is
>   begin
>      raise Program_Error with "Not yet implemented";
>      return F;
>   end F;

I think that one is a compiler-fall-over test, at least if the return type 
is a limited and required build-in-place. :-) Not so much for Boolean (but 
of course "return False" works fine there).

                              Randy.