!standard 13.12 (4) 04-06-17 AI95-00381/02 !standard 13.12.1 (1) !class amendment 04-06-08 !status Amendment 200Y 04-06-29 !status ARG Approved 11-0-1 04-06-17 !status work item 04-06-08 !status received 04-06-08 !priority Medium !difficulty Easy !subject New Restrictions identifier No_Dependence !summary A new Restrictions identifier is proposed to specify that there are no dependences on a given language-defined or implementation-defined package. !problem There are a number of Restrictions identifiers provided for disallowing dependence on one language-defined package or another. Rather than adding more of these identifiers piece-meal, it would make sense to have a general No_Dependence restriction, identifying the restricted package by the expression associated with the restriction. !proposal (See wording.) !wording Change 13.12(4) to: restriction ::= restriction_identifier | restriction_parameter_identifier => restriction_parameter_argument restriction_parameter_argument ::= name | expression New section 13.12.1: 13.12.1 Restriction No_Dependence Static Semantics The following restriction_parameter_identifier is language defined: No_Dependence Specifies a language-defined library unit on which there are no semantic dependences. Name Resolution Rules The restriction_parameter_argument of a No_Dependence restriction shall be a name that corresponds to the full expanded name of a language-defined library unit. Post-Compilation Rule No compilation unit included in the partition shall depend semantically on the library unit identified by the name. !discussion This restriction should reduce the need for having a separate restriction identifier for each potentially interesting language-defined library unit. We considered using a static string identify the library unit, as this would allow a "wildcard" notation (like "Ada.Wide_*"), and would require less changes to the existing language. But it was just too unnatural. !example pragma Restrictions(No_Dependence => Ada.Command_Line); -- Example of restriction on language-defined package !ACATS test An ACATS test should be created for this pragma. !corrigendum 13.12(4) @drepl @xcode<@fa@ft<@i>@fa<_identifier | >@ft<@i>@fa<_identifier =@> expression>> @dby @xcode<@fa@ft<@i>@fa<_identifier | >@ft<@i>@fa<_identifier =@> restriction_parameter_argument> restriction_parameter_argument ::= name | expression> !corrigendum 13.12.1(1) @dinsc @i<@s8> The following @i@fa<_identifier> is language defined: @xhang<@xterm Specifies a language-defined library unit on which there are no semantic dependences.> @i<@s8> The @fa of a No_Dependence restriction shall be a name that corresponds to the full expanded name of a language-defined library unit. @i<@s8> No compilation unit included in the partition shall depend semantically on the library unit identified by the @fa. !appendix From: Tucker Taft Sent: Monday, June 7, 2004 11:48 PM Here is my last homework assignment (I hope, and probably so do you ;-). It is a proposal to add a restriction-parameter identifier "No_Dependence" whose expression is a static string identifying a language-defined or implementation-defined library unit. No compilation unit in the partition may have a semantic dependence on this library unit. I chose to use a static string rather than an unquoted name to conform to the basic syntax of restriction_parameter_identifier => expression This decision is debatable. See the !discussion for a bit more rationale. **************************************************************** From: Robert A Duff Sent: Wednesday, June 9, 2004 10:30 AM I don't care much one way or the other, but I suspect most users would find the quotes to be superfluous. Also, I wonder whether the string can contain blanks and other whitespace: pragma Restrictions (No_Dependence => "Ada. " & ascii.nl & " Command_Line"); I don't want to clutter the RM with rules forbidding such. But when it comes to ascii.nl, whether that's whitespace might be considered implementation dependent. Does "Ada.Command_Line -- comment" correspond to a full expanded name? Syntactically using a 'name' avoids worrying about such silliness. I realize it might complicate the wording. ****************************************************************