CVS difference for ai05s/ai05-0229-1.txt
--- ai05s/ai05-0229-1.txt 2011/10/21 06:42:22 1.22
+++ ai05s/ai05-0229-1.txt 2011/11/01 05:32:53 1.23
@@ -446,7 +446,7 @@
Modify 6.5.1(10/2):
procedure Fail(Msg : String)[;]; -- raises Fatal_Error exception
- with No_Return => True;}
+ with No_Return;}
[pragma No_Return(Fail);]
-- Inform compiler and reader that procedure never returns normally
@@ -454,7 +454,7 @@
procedure Raise_Exception(E : in Exception_Id;
Message : in String := ""){
- with No_Return => True};
+ with No_Return};
[pragma No_Return(Raise_Exception);]
[This is the only use of No_Return in an Ada predefined package.]
@@ -983,7 +983,7 @@
AARM Ramification: If the Storage_Size aspect is not specified for the type of
the task object, the value of the Storage_Size attribute is unspecified.
-Add to J.9(3/2):
+Add to J.9(3/2):
When the attribute is specified, the Storage_Size aspect
is specified to be the value of the given expression.
@@ -1821,7 +1821,7 @@
Legality Rules
-The local_name of of each of these pragmas shall denote a declaration that may have
+The local_name of each of these pragmas shall denote a declaration that may have
the similarly named aspect specified.
J.15.9 pragma CPU
@@ -2209,9 +2209,9 @@
!corrigendum 2.8(18)
@drepl
-@xbullet<A pragma used to complete a declaration, such as a pragma Import;>
+@xbullet<A @fa<pragma> used to complete a declaration, such as a pragma Import;>
@dby
-@xbullet<A pragma used to complete a declaration;>
+@xbullet<A @fa<pragma> used to complete a declaration;>
!corrigendum 2.8(29/2)
@@ -2224,7 +2224,8 @@
@xcode<@b<pragma> List(Off); --@ft<@i< turn off listing generation>>
@b<pragma> Optimize(Off); --@ft<@i< turn off optional optimizations>>
@b<pragma> Pure(Rational_Numbers); --@ft<@i< set categorization for package>>
-@b<pragma> Assert(Exists(File_Name), Message => "Nonexistent file"); --@ft<@i< assert file exists>>>
+@b<pragma> Assert(Exists(File_Name),
+ Message => "Nonexistent file"); --@ft<@i< assert file exists>>>
!corrigendum 3.6.2(11)
@@ -2233,12 +2234,12 @@
An implementation should normally represent multidimensional arrays in row-major order,
consistent with the notation used for multidimensional array aggregates (see 4.3.3).
However, if a @b<pragma> Convention(Fortran, ...) applies to a multidimensional
-array type, then column-major order should be used instead (see B.5, “Interfacing with Fortran”).
+array type, then column-major order should be used instead (see B.5, "Interfacing with Fortran").
@dby
An implementation should normally represent multidimensional arrays in row-major order,
consistent with the notation used for multidimensional array aggregates (see 4.3.3).
However, if convention Fortran is specified for a multidimensional
-array type, then column-major order should be used instead (see B.5, “Interfacing with Fortran”).
+array type, then column-major order should be used instead (see B.5, "Interfacing with Fortran").
!corrigendum 3.7(37/2)
@@ -2252,7 +2253,7 @@
@b<end> Worker;>
@dby
@xcode<@b<task type> Worker(Prio : System.Priority; Buf : @b<access> Buffer)
- @b<with> Priority => Prio @b<is> --@ft<@i< see D.1>>
+ @b<with> Priority =@> Prio @b<is> --@ft<@i< see D.1>>
--@ft<@i< discriminants used to parameterize the task type (see 9.1)>>
@b<entry> Fill;
@b<entry> Drain;
@@ -2281,20 +2282,20 @@
@b<function> Ada.Tags.Generic_Dispatching_Constructor
(The_Tag : Tag;
Params : @b<not null access> Parameters) @b<return> T'Class
- @b<with> Convention => Intrinsic;
+ @b<with> Convention =@> Intrinsic;
@b<pragma> Preelaborate(Generic_Dispatching_Constructor);>
!corrigendum 3.11(11)
@drepl
-@xbullet<For a call to a protected operation of a protected type (that has a body — no check is performed
+@xbullet<For a call to a protected operation of a protected type (that has a body @emdash no check is performed
if a @fa<pragma> Import applies to the protected type), a check is made that the @fa<protected_body>
is already elaborated. This check and the evaluations of any actual parameters of the call are done
in an arbitrary order.>
@dby
-@xbullet<For a call to a protected operation of a protected type (that has a body — no check is performed
-if the protected type is imported - see B.1), a check is made that the @fa<protected_body>
+@xbullet<For a call to a protected operation of a protected type (that has a body @emdash no check is performed
+if the protected type is imported @emdash see B.1), a check is made that the @fa<protected_body>
is already elaborated. This check and the evaluations of any actual parameters of the call are done
in an arbitrary order.>
@@ -2495,7 +2496,7 @@
--@ft<@i< Inform compiler and reader that procedure never returns normally>>>
@dby
@xcode<@b<procedure> Fail(Msg : String) --@ft<@i< raises Fatal_Error exception>>
- @b<with> No_Return =@> True;
+ @b<with> No_Return;
--@ft<@i< Inform compiler and reader that procedure never returns normally>>>
@@ -2536,11 +2537,11 @@
@drepl
@xcode<CPU_Identifier : @b<constant> String(1..8);
@b<pragma> Import(Assembler, CPU_Identifier, Link_Name => "CPU_ID");
- --@i<@ft< see B.1>>>
+ --@ft<@i< see B.1>>>
@dby
@xcode<CPU_Identifier : @b<constant> String(1..8)
- @b<with> Import => True, Convention => Assembler, Link_Name => "CPU_ID";
- --@i<@ft< see B.1>>>
+ @b<with> Import =@> True, Convention =@> Assembler, Link_Name =@> "CPU_ID";
+ --@ft<@i< see B.1>>>
!corrigendum 9.10(1)
@@ -2571,10 +2572,10 @@
@drepl
A @fa<pragma> Atomic or Atomic_Components may also be used to ensure that
-certain reads and updates are sequential — see C.6.
+certain reads and updates are sequential @emdash see C.6.
@dby
Aspect Atomic or aspect Atomic_Components may also be specified to ensure
-that certain reads and updates are sequential — see C.6.
+that certain reads and updates are sequential @emdash see C.6.
!corrigendum 10.1.4(7/2)
@@ -2659,7 +2660,7 @@
@dby
@xcode< @b<procedure> Raise_Exception(E : @b<in> Exception_Id;
Message : @b<in> String := "")
- @b<with> No_Return =@> True;
+ @b<with> No_Return;
@b<function> Exception_Message(X : Exception_Occurrence) @b<return> String;
@b<procedure> Reraise_Occurrence(X : @b<in> Exception_Occurrence);>
@@ -2682,7 +2683,7 @@
If an exception is raised due to the failure of a language-defined check, then upon
reaching the corresponding @fa<exception_handler> (or the termination of the task,
if none), the external interactions that have occurred need reflect only that the
-exception was raised somewhere within the execution of the @nt<sequence_of_statements>
+exception was raised somewhere within the execution of the @fa<sequence_of_statements>
with the handler (or the @fa<task_body>), possibly earlier (or later if the interactions
are independent of the result of the checked operation) than that defined by the canonical
semantics, but not within the execution of some abort-deferred operation or @i<independent>
@@ -2696,7 +2697,7 @@
If an exception is raised due to the failure of a language-defined check, then upon
reaching the corresponding @fa<exception_handler> (or the termination of the task,
if none), the external interactions that have occurred need reflect only that the
-exception was raised somewhere within the execution of the @nt<sequence_of_statements>
+exception was raised somewhere within the execution of the @fa<sequence_of_statements>
with the handler (or the @fa<task_body>), possibly earlier (or later if the interactions
are independent of the result of the checked operation) than that defined by the canonical
semantics, but not within the execution of some abort-deferred operation or @i<independent>
@@ -2803,7 +2804,7 @@
the following language-defined representation aspect may be specified:
@xhang<@xTerm<Storage_Size>
-The aspect Storage_Size is an expression, which shall be of
+The aspect Storage_Size is an @fa<expression>, which shall be of
any integer type.>
@s8<@i<Legality Rules>>
@@ -2818,8 +2819,10 @@
@fa<pragma> Storage_Size, the @fa<expression> is evaluated; the Storage_Size attribute
of the newly created task object is at least the value of the @fa<expression>.
@dby
+When a task object is created, the @fa<expression> (if any) associated with the
+Storage_Size aspect of its type is evaluated; the Storage_Size attribute of the newly
+created task object is at least the value of the @fa<expression>.
-
!corrigendum 13.3(73)
@drepl
@@ -3010,7 +3013,7 @@
The Link_Name and External_Name aspects are of type String.
-The expected type for the @i<string_>@fa<expression> in pragma Linker_Options, is
+The expected type for the @i<string_>@fa<expression> in pragma Linker_Options is
String.
!comment %% B.1(11), B.1(14), B.1(21), and B.1(22) need changes here.
@@ -3053,7 +3056,7 @@
@dby
The @fa<aspect_definition> (if any) used to directly specify an Import,
Export, External_Name, or Link_Name aspect shall be a static expression.
-The @i<string_>@fa<expression> of a pragma Linker_Options
+The @i<string_>@fa<expression> of a @fa<pragma> Linker_Options
shall be static. An External_Name or Link_Name aspect shall be specified
only for an entity that is either imported or exported.
@@ -3243,11 +3246,11 @@
!corrigendum B.3(78)
@drepl
-@xcode< -- @i<@ft<Note: since the C function's return value is of no interest, the Ada interface is a procedure>>
+@xcode< @ft<@i<-- Note: since the C function's return value is of no interest, the Ada interface is a procedure>>
@b<procedure> Strcpy (Target : @b<out> C.char_array;
Source : @b<in> C.char_array);>
@dby
-@xcode< -- @i<@ft<Note: since the C function's return value is of no interest, the Ada interface is a procedure>>
+@xcode< @ft<@i<-- Note: since the C function's return value is of no interest, the Ada interface is a procedure>>
@b<procedure> Strcpy (Target : @b<out> C.char_array;
Source : @b<in> C.char_array)
@b<with> Import =@> True, Convention =@> C, External_Name =@> "strcpy";>
@@ -3263,14 +3266,14 @@
The package Interfaces.C.Strings declares types and subprograms allowing an Ada program to
allocate, reference, update, and free C-style strings. In particular, the private type chars_ptr
corresponds to a common use of “char *” in C programs, and an object of this type can be passed
-to a subprogram to which pragma Import(C,...) has been applied, and for which “char *” is the
+to a subprogram to which pragma Import(C,...) has been applied, and for which "char *" is the
type of the argument of the C function.
@dby
The package Interfaces.C.Strings declares types and subprograms allowing an Ada program to
allocate, reference, update, and free C-style strings. In particular, the private type chars_ptr
-corresponds to a common use of “char *” in C programs, and an object of this type can be passed
-to a subprogram to which @ft<@b<with> Import => True, Convention => C> has been specified, and for
-which “char *” is the type of the argument of the C function.
+corresponds to a common use of "char *" in C programs, and an object of this type can be passed
+to a subprogram to which @fc<@b<with> Import =@> True, Convention =@> C> has been specified, and for
+which "char *" is the type of the argument of the C function.
@@ -3386,7 +3389,7 @@
The @fa<expression> specified for the Attach_Handler aspect of a protected procedure @i<P>
is evaluated as part of the creation of the protected object that contains @i<P>.
The value of the @fa<expression> identifies an interrupt. As part of the initialization
-of that object, @i<P> (the @fa<handler> procedure) is attached to the
+of that object, @i<P> (the @i<handler> procedure) is attached to the
identified interrupt. A check is made that the corresponding interrupt is not reserved.
Program_Error is raised if the check fails, and the existing treatment for the interrupt is not
affected.
@@ -3472,13 +3475,13 @@
@drepl
The Attach_Handler procedure attaches the specified handler to the interrupt, overriding any
existing treatment (including a user handler) in effect for that interrupt. If New_Handler is
-null, the default treatment is restored. If New_Handler designates a protected procedure to
+@b<null>, the default treatment is restored. If New_Handler designates a protected procedure to
which the pragma Interrupt_Handler does not apply, Program_Error is raised. In this case, the
operation does not modify the existing interrupt treatment.
@dby
The Attach_Handler procedure attaches the specified handler to the interrupt, overriding any
existing treatment (including a user handler) in effect for that interrupt. If New_Handler is
-null, the default treatment is restored. If New_Handler designates a protected procedure for
+@b<null>, the default treatment is restored. If New_Handler designates a protected procedure for
which the aspect Interrupt_Handler is False, Program_Error is raised. In this case, the
operation does not modify the existing interrupt treatment.
@@ -3502,7 +3505,7 @@
the same for all interrupts.
@dby
If the Ceiling_Locking policy (see D.3) is in effect, the implementation shall document the
-default ceiling priority assigned to a protected object that contains a protected procedures
+default ceiling priority assigned to a protected object that contains a protected procedure
that specifies either the Attach_Handler
or Interrupt_Handler aspects, but does not specify the Interrupt_Priority aspect. This default
need not be the same for all interrupts.
@@ -3562,9 +3565,9 @@
If aspect Independent_Components is specified for a
@fa<full_type_declaration>, the declaration shall be that of an array or record type.
-It is illegal to specify the aspect Atomic or Atomic_Components to have the value True
-for an object or type if the implementation cannot support the indivisible reads and writes
-required by the aspect (see below).
+It is illegal to specify either of the aspects Atomic or Atomic_Components to have the value
+True for an object or type if the implementation cannot support the indivisible reads and
+updates required by the aspect (see below).
!corrigendum C.6(13)
@@ -3572,7 +3575,7 @@
If a pragma Volatile, Volatile_Components, Atomic, or Atomic_Components applies to a stand-alone
constant object, then a pragma Import shall also apply to it.
@dby
-If an aspect Volatile, Volative_components, Atomic or Atomic_Components is
+If an aspect Volatile, Volatile_Components, Atomic, or Atomic_Components is
directly specified to have the value True for a stand-alone constant object,
then the aspect Import shall also be specified as True for it.
@@ -3728,12 +3731,12 @@
@drepl
If the locking policy Ceiling_Locking is in effect, then for a protected object @i<P> with either
an Attach_Handler or Interrupt_Handler pragma applying to one of its procedures, a check is
-made that the value to be assigned to P'Priority is in the range System.Interrupt_Priority.
+made that the value to be assigned to @i<P>'Priority is in the range System.Interrupt_Priority.
If the check fails, Program_Error is raised.
@dby
If the locking policy Ceiling_Locking is in effect, then for a protected object @i<P> with either
an Attach_Handler or Interrupt_Handler aspect specified for one of its procedures, a check is
-made that the value to be assigned to P'Priority is in the range System.Interrupt_Priority.
+made that the value to be assigned to @i<P>'Priority is in the range System.Interrupt_Priority.
If the check fails, Program_Error is raised.
@@ -3776,15 +3779,15 @@
@drepl
If a pragma All_Calls_Remote applies to a given RCI library unit, then the implementation shall
-route any call to a subprogram of the RCI unit package from outside the declarative region of the
+route any call to a subprogram of the RCI unit from outside the declarative region of the
unit through the Partition Communication Subsystem (PCS); see E.5. Calls to such subprograms from
-within the declarative region of the unit package are defined to be local and shall not go through
+within the declarative region of the unit are defined to be local and shall not go through
the PCS.
@dby
If aspect All_Calls_Remote is True for a given RCI library unit, then the implementation shall
-route any call to a subprogram of the RCI unit package from outside the declarative region of the
+route any call to a subprogram of the RCI unit from outside the declarative region of the
unit through the Partition Communication Subsystem (PCS); see E.5. Calls to such subprograms from
-within the declarative region of the unit package are defined to be local and shall not go through
+within the declarative region of the unit are defined to be local and shall not go through
the PCS.
@@ -3865,13 +3868,13 @@
@drepl
If COBOL (respectively, C) is widely supported in the target environment, implementations supporting
the Information Systems Annex should provide the child package Interfaces.COBOL (respectively,
-Interfaces.C) specified in Annex B and should support a convention_identifier of COBOL (respectively,
+Interfaces.C) specified in Annex B and should support a @i<convention_>@fa<identifier> of COBOL (respectively,
C) in the interfacing pragmas (see Annex B), thus allowing Ada programs to interface with programs
written in that language.
@dby
If COBOL (respectively, C) is widely supported in the target environment, implementations supporting
the Information Systems Annex should provide the child package Interfaces.COBOL (respectively,
-Interfaces.C) specified in Annex B and should support a convention_identifier of COBOL (respectively,
+Interfaces.C) specified in Annex B and should support a @i<convention_>@fa<identifier> of COBOL (respectively,
C) for the Convention aspect (see Annex B), thus allowing Ada programs to interface with programs
written in that language.
@@ -3899,21 +3902,21 @@
Divisor : @b<in> Divisor_Type;
Quotient : @b<out> Quotient_Type;
Remainder : @b<out> Remainder_Type)
- @b<with> Convention => Intrinsic;>
+ @b<with> Convention =@> Intrinsic;>
!corrigendum G(7)
@drepl
If Fortran (respectively, C) is widely supported in the target environment, implementations supporting
-the Information Systems Annex should provide the child package Interfaces.Fortran (respectively,
-Interfaces.C) specified in Annex B and should support a convention_identifier of Fortran (respectively,
+the Numerics Annex should provide the child package Interfaces.Fortran (respectively,
+Interfaces.C) specified in Annex B and should support a @i<convention_>@fa<identifier> of Fortran (respectively,
C) in the interfacing pragmas (see Annex B), thus allowing Ada programs to interface with programs
written in that language.
@dby
If Fortran (respectively, C) is widely supported in the target environment, implementations supporting
-the Information Systems Annex should provide the child package Interfaces.Fortran (respectively,
-Interfaces.C) specified in Annex B and should support a convention_identifier of Fortran (respectively,
+the Numerics Annex should provide the child package Interfaces.Fortran (respectively,
+Interfaces.C) specified in Annex B and should support a @i<convention_>@fa<identifier> of Fortran (respectively,
C) for the Convention aspect (see Annex B), thus allowing Ada programs to interface with programs
written in that language.
@@ -3941,10 +3944,10 @@
@s8<@i<Syntax>>
-The form of a pragma Inline, which is a program unit pragma (see
+The form of a @fa<pragma> Inline, which is a program unit pragma (see
10.1.5), is as follows:
-@xcode<@ft<@b<pragma> Inline(@fa<name> {, @fa<name>});>>
+@xcode<@ft<@b<pragma> Inline (@fa<name>{, @fa<name>});>>
@s8<@i<Legality Rules>>
@@ -3975,7 +3978,7 @@
The form of a @fa<pragma> No_Return, which is a representation pragma (see 13.1),
is as follows:
-@xcode<@ft<@b<pragma> No_Return(@i<procedure_>@fa<local_name>{, @i<procedure_>@fa<local_name>});>>
+@xcode<@ft<@b<pragma> No_Return (@i<procedure_>@fa<local_name>{, @i<procedure_>@fa<local_name>});>>
@s8<@i<Legality Rules>>
@@ -3985,7 +3988,7 @@
@s8<@i<Static Semantics>>
-@fa<Pragma> No_Return specifies that the No_Return aspect (see 6.3.2) for each
+@fa<Pragma> No_Return specifies that the No_Return aspect (see 6.5.1) for each
procedure denoted by each @fa<local_name> given in the @fa<pragma> has the value True.
!corrigendum J.15.3(0)
@@ -3997,7 +4000,7 @@
The form of a @fa<pragma> Pack, which is a representation pragma (see 13.1),
is as follows:
-@xcode<@ft<@b<pragma> Pack(@i<first_subtype_>@fa<local_name>);>>
+@xcode<@ft<@b<pragma> Pack (@i<first_subtype_>@fa<local_name>);>>
@s8<@i<Legality Rules>>
@@ -4017,7 +4020,7 @@
The form of a @fa<pragma> Storage_Size is as follows:
-@xcode<@ft<@b<pragma> Storage_Size(@fa<expression>);>>
+@xcode<@ft<@b<pragma> Storage_Size (@fa<expression>);>>
A @fa<pragma> Storage_Size is allowed only immediately within a @fa<task_definition>.
@@ -4037,20 +4040,20 @@
@s8<@i<Syntax>>
-An @i<interfacing> pragma is a representation pragma that is one of the pragmas Import,
+An @i<interfacing pragma> is a representation pragma that is one of the @fa<pragma>s Import,
Export, or Convention. Their forms are as follows:
-@xcode<@ft<@b<pragma> Import(@hr
+@xcode<@ft<@b<pragma> Import (
[Convention =@>] @i<convention_>@fa<identifier>, [Entity =@>] @fa<local_name>
[, [External_Name =@>] @i<external_name_string_>@fa<expression>]
[, [Link_Name =@>] @i<link_name_string_>@fa<expression>]);>>
-@xcode<@ft<@b<pragma> Export(@hr
+@xcode<@ft<@b<pragma> Export (
[Convention =@>] @i<convention_>@fa<identifier>, [Entity =@>] @fa<local_name>
[, [External_Name =@>] @i<external_name_string_>@fa<expression>]
[, [Link_Name =@>] @i<link_name_string_>@fa<expression>]);>>
-@xcode<@ft<@b<pragma> Convention([Convention =@>] @i<convention_>@fa<identifier>,[Entity =@>] @fa<local_name>);>>
+@xcode<@ft<@b<pragma> Convention ([Convention =@>] @i<convention_>@fa<identifier>,[Entity =@>] @fa<local_name>);>>
For pragmas Import and Export, the argument for Link_Name shall not be given without
the @i<pragma_argument_>@fa<identifier> unless the argument for External_Name is given.
@@ -4123,11 +4126,11 @@
The form of a @fa<pragma> Interrupt_Handler is as follows:
-@xindent<@b<pragma> Interrupt_Handler(@i<handler_>@fa<name>);>
+@xindent<@b<pragma> Interrupt_Handler (@i<handler_>@fa<name>);>
-The form of a pragma Attach_Handler is as follows:
+The form of a @fa<pragma> Attach_Handler is as follows:
-@xcode<@ft<@b<pragma> Attach_Handler(@i<handler_>@fa<name>, @fa<expression>);>>
+@xcode<@ft<@b<pragma> Attach_Handler (@i<handler_>@fa<name>, @fa<expression>);>>
@s8<@i<Name Resolution Rules>>
@@ -4164,17 +4167,17 @@
The form for @fa<pragma>s Atomic, Volatile, Independent, Atomic_Components, and
Volatile_Components, and Independent_Components is as follows:
-@xcode<@ft<@b<pragma> Atomic(@fa<local_Name>);>>
+@xcode<@ft<@b<pragma> Atomic (@fa<local_name>);>>
-@xcode<@ft<@b<pragma> Volatile(@fa<local_Name>);>>
+@xcode<@ft<@b<pragma> Volatile (@fa<local_name>);>>
-@xcode<@ft<@b<pragma> Atomic(@i<component_>@fa<local_Name>);>>
+@xcode<@ft<@b<pragma> Atomic (@i<component_>@fa<local_name>);>>
-@xcode<@ft<@b<pragma> Atomic_Components(@i<array_>@fa<local_Name>);>>
+@xcode<@ft<@b<pragma> Atomic_Components (@i<array_>@fa<local_name>);>>
-@xcode<@ft<@b<pragma> Volatile_Components(@i<array_>@fa<local_Name>);>>
+@xcode<@ft<@b<pragma> Volatile_Components (@i<array_>@fa<local_name>);>>
-@xcode<@ft<@b<pragma> Independent_Components(@fa<local_Name>);>>
+@xcode<@ft<@b<pragma> Independent_Components (@fa<local_name>);>>
@s8<@i<Name Resolution Rules>>
@@ -4196,7 +4199,7 @@
@s8<@i<Legality Rules>>
-The @fa<local_name> of of each of these @fa<pragma>s shall denote a declaration that
+The @fa<local_name> of each of these @fa<pragma>s shall denote a declaration that
may have the similarly named aspect specified.
!corrigendum J.15.9
@@ -4207,11 +4210,11 @@
The form of a @fa<pragma> CPU is as follows:
-@xcode<@ft<@b<pragma> CPU(@fa<expression>);>>
+@xcode<@ft<@b<pragma> CPU (@fa<expression>);>>
@s8<@i<Name Resolution Rules>>
-The expected type for the @fa<expression> of a pragma CPU is
+The expected type for the @fa<expression> of a @fa<pragma> CPU is
System.Multiprocessors.CPU_Range.
@s8<@i<Legality Rules>>
@@ -4235,15 +4238,17 @@
!corrigendum J.15.11
+@dinsc
+
@s8<@i<Syntax>>
The form of a @fa<pragma> Priority is as follows:
-@xcode<@ft<@b<pragma> Priority(@fa<expression>);>>
+@xcode<@ft<@b<pragma> Priority (@fa<expression>);>>
The form of a @fa<pragma> Interrupt_Priority is as follows:
-@xcode<@ft<@b<pragma> Interrupt_Priority[(@fa<expression>)];>>
+@xcode<@ft<@b<pragma> Interrupt_Priority [(@fa<expression>)];>>
@s8<@i<Name Resolution Rules>>
@@ -4257,7 +4262,7 @@
An Interrupt_Priority pragma is allowed only immediately within a @fa<task_definition>
or a @fa<protected_definition>.
-For a Priority pragma that appears in the @fa<declarative_part> of a @fa<subprogram_body,>
+For a Priority pragma that appears in the @fa<declarative_part> of a @fa<subprogram_body>,
the @fa<expression> shall be static, and its value shall be in the range of
System.Priority.
@@ -4319,7 +4324,7 @@
The form of a @fa<pragma> Asynchronous, which is a representation pragma (see 13.1),
is as follows:
-@xcode<@ft<@b<pragma> Asynchronous(@fa<local_name>);>>
+@xcode<@ft<@b<pragma> Asynchronous (@fa<local_name>);>>
@s8<@i<Static Semantics>>
@@ -8525,10 +8530,11 @@
From: Randy Brukardt
Sent: Friday, September 30, 2011 11:57 PM
-This *is* bizarre, but dropping the attribute specification would be highly incompatible.
-At least one Ada user I know really well (me) only uses this form because he hates the
-pragmas so much that he never implemented them. Dropping this attribute_definition_clause
-would break all of my programs (including Claw). I doubt I'm the only one.
+This *is* bizarre, but dropping the attribute specification would be highly
+incompatible. At least one Ada user I know really well (me) only uses this form
+because he hates the pragmas so much that he never implemented them. Dropping
+this attribute_definition_clause would break all of my programs (including
+Claw). I doubt I'm the only one.
And forcing the semantics to work like the old pragma and the new aspect isn't practical
-- the aspect specifies an *expression*, that is evaluated per-object, while an
@@ -8982,6 +8988,246 @@
the wrong font. It is not the syntactic notion of expression, but the semantic
one, as in 7/3.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, September 28, 2011 11:51 PM
+
+In Bob's review of 11.4.1, he writes:
+
+> 4/3 procedure Raise_Exception(E : in Exception_Id;
+> Message : in String := "")
+> with No_Return => True;
+
+"with No_Return => True" --> "with No_Return"?
+Why not take advantage of the shorthand?
+Seems more readable.
+
+--------------------
+
+In Tucker's review of 13.1, he writes:
+
+13.1 7.c/3, 14.e/3 (a total of 3 places):
+
+ ... with Pack {=> True}; ...
+
+--------------------
+
+It seems to me that if I follow both of these suggestions, I'll probably get
+more comments during the next review. :-)
+
+I admit that I wasn't very consistent about using the shorthand: I only used it
+for Pack. None of the other aspects seemed to read that well. (The primary
+trouble is "with"; but since no one has ever suggested an alternative that
+seemed any better -- even a new keyword -- we're pretty much stuck with that.)
+
+The aspects involved are at least Pack, No_Return, and Import. The latter is
+always followed by Convention, and it would (IMHO) look weird without the "=>
+True" -- like a positional parameter before a named one. The other two are no as
+clear-cut. (There may be others for which I did use the shortcut, it would be
+hard to check for those.)
+
+In any case, I'm not going to make any change here unless there is some sort of
+consensus as to whether or not to use the shorthand form in the Standard. So you
+guys argue it out between yourselves (I have plenty of other things to work on).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, September 29, 2011 9:33 AM
+
+Some aspects read better than others
+in my view without the "=> True".
+To me, "with Pack" sounds weird, but
+"with No_Return" sounds reasonable.
+I agree we should be consistent for
+a particular aspect, but I don't see
+the need for us to use "=> True" always
+or never for all boolean aspects.
+And none of these are show-stoppers...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, September 29, 2011 5:07 PM
+
+> Some aspects read better than others
+> in my view without the "=> True".
+
+I agree so far...
+
+> To me, "with Pack" sounds weird, but
+> "with No_Return" sounds reasonable.
+
+...but I feel exactly the reverse ("with Pack" seems fine, "with No_Return"
+seems weird).
+
+> I agree we should be consistent for
+> a particular aspect, but I don't see
+> the need for us to use "=> True" always or never for all boolean
+> aspects.
+> And none of these are show-stoppers...
+
+Right. Part of my thinking for Pack was that "with Pack" seems a bit weird, but
+"with Pack => True" seems worse. After all, if you write "True", it ought to
+make sense to write "False", and "with Pack => False" seems like complete
+nonsense to me. [We'll ignore for the moment that Pack itself is close to
+nonsense.] OTOH, "with No_Return => False" seems to make sense (although it is a
+double negative).
+
+Anyway, I think it matters what Bob and others think as well. (Right now, I'm
+leaning toward taking Bob's comment and ignoring yours, but I want to know what
+others think.)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, September 29, 2011 5:41 PM
+
+> > To me, "with Pack" sounds weird, but "with No_Return" sounds
+> > reasonable.
+>
+> ...but I feel exactly the reverse ("with Pack" seems fine, "with No_Return"
+> seems weird).
+
+I could go either way on both.
+
+> Anyway, I think it matters what Bob and others think as well. (Right
+> now, I'm leaning toward taking Bob's comment and ignoring yours, but I
+> want to know what others think.)
+
+I do not think it's important that the RM is consistent on this point.
+I think individual Ada projects will want to have a consistent style, but it's
+OK if the RM does not. Maybe it's even better to illustrate that both styles
+work.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, September 29, 2011 5:54 PM
+
+For me, I expect a noun or a phrase after "with," never just a single verb. And
+"Pack" is a verb, while "No Return" is a noun phrase. So "with Pack" doesn't
+make sense to me grammatically, while "with No_Return" sounds just fine
+grammatically.
+
+"with Packing" would sound fine, but I agree with our earlier decision to use
+the pragma names, even if they are awkward alone after "with."
+
+I also don't understand your objection to "with Pack => False;" for what that's
+worth. I could easily imagine declaring
+
+ type Bool_Vector is array(Positive range <>) of Boolean
+ with Pack => False;
+
+to emphasize that unlike most vectors of Booleans, we do *not* want this one
+packed. This would be a warning to maintainers, presumably, that speed of
+access is more important than space considerations for this vector.
+
+And "with No_Return => False" seems downright weird to me, so we seem to have
+varying mileage on this one!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, September 30, 2011 3:55 AM
+
+> And "with No_Return => False" seems downright weird to me, so we seem
+> to have varying mileage on this one!
+
+which is a good thing, since it is the only reasonable justification for having
+two ways of doing things :-) :-)
+
+****************************************************************
+
+From: John Barnes
+Sent: Friday, September 30, 2011 7:49 AM
+
+>> To me, "with Pack" sounds weird, but
+>> "with No_Return" sounds reasonable.
+>
+> ...but I feel exactly the reverse ("with Pack" seems fine, "with
+> No_Return"
+> seems weird).
+
+Obviously should be "with out Return"
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Friday, September 30, 2011 11:52 AM
+
+> > ...but I feel exactly the reverse ("with Pack" seems fine, "with
+> > No_Return"
+> > seems weird).
+>
+> Obviously should be "with out Return"
+
+and obviously, "with Pack" should be
+
+ type A is packed array ...
+
+Maybe in Ada 2020 we will be back to Pascal.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, October 1, 2011 9:01 AM
+
+> and obviously, "with Pack" should be
+>
+> type A is packed array ...
+
+I sort of hope a smiley is missing here, and that this is not a serious
+suggestion!
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Saturday, October 1, 2011 11:23 AM
+
+Why would you say that?
+
+Don't you think adjectives go well before nouns?
+Do you think we should say
+ type T is record ... end record with tagged => true;
+ type T is record ... end record with limited => true;
+ type T is record ... end record with abstract => true;
+
+Ada 83 removed a lot of useful features from Pascal, including sets, subprogram
+pointers, in/out parameters on functions, packed as an array modifier, etc., and
+the trend ever since has been to gradually restore those features to the
+language.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, October 1, 2011 5:48 PM
+
+> Don't you think adjectives go well before nouns?
+> Do you think we should say
+> type T is record ... end record with tagged => true;
+> type T is record ... end record with limited => true;
+> type T is record ... end record with abstract => true;
+
+We might have considered such if we had had aspects from the start, although my
+taste is that the above have verty different semantic force from packed.
+
+> Ada 83 removed a lot of useful features from Pascal, including sets,
+> subprogram pointers, in/out parameters on functions, packed as an
+> array modifier, etc.,
+
+I find the last one in the list here oddly out of place, since it is just a
+syntactic issue, and for me I think the idea of having piles of keywords as
+modifers such as packed is simply horrible, so given that you are making this as
+a serious suggestion, I strongly object, and think it would be very undesirable
+to
+
+a) introduce a new keyword packed
+
+b) have three ways of saying an array is packed (bad enough having
+two!)
****************************************************************
Questions? Ask the ACAA Technical Agent