CVS difference for ai05s/ai05-0242-1.txt
--- ai05s/ai05-0242-1.txt 2011/02/11 06:38:10 1.1
+++ ai05s/ai05-0242-1.txt 2011/02/16 06:15:23 1.2
@@ -51,6 +51,10 @@
Add a ACATS B test for this feature.
+!ASIS
+
+No ASIS effect (Restrictions are not handled specially by ASIS).
+
!appendix
From: Robert Dewar
@@ -557,3 +561,1369 @@
****************************************************************
+From: Jean-Pierre Rosen
+Sent: Friday, February 11, 2011 12:44 AM
+
+> In any case, the use of System is inherently non-portable.
+
+I don't agree with this statement. You have two kinds of portability: programs
+that give exactly the same result on any implementation, and programs that adapt
+automatically to the variations in the implementation. System is for the latter.
+
+And later:
+> And then the question is whether people really are going to use all of
+> these restrictions. That seems doubtful as well.
+
+I have several clients whose programming rules forbid the use of implementation
+defined identifiers in System. Currently, I scan System and make an AdaControl
+rule to forbid these. A simple restriction would be more efficient, and safer
+(you have to check System every time a new version of the compiler appears).
+
+BTW, restrictions are nice, because they cause no harm: if you don't like a
+restriction, don't use it.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 11, 2011 1:49 AM
+
+...
+> BTW, restrictions are nice, because they cause no harm: if you don't
+> like a restriction, don't use it.
+
+No harm, maybe, but they're expensive for both users and implementers.
+
+Two points which you may have missed:
+ (1) None of these restrictions are partition-wide, because the runtime has to
+ be able to depend on implementation-defined stuff. As such, you'll have
+ to repeat them in every compilation in your system. Moreover, at this
+ point there are 5 of these things (and you want to add a 6th), so you
+ have a block of 6 pragmas at the top of *every* compilation unit. Can you
+ say noise?? I'd rather use AdaControl (really: it's too bad that it
+ requires being able to compile a program with GNAT before it can be used;
+ that prevents using it on most Janus/Ada code). I doubt many would do
+ that.
+
+ (2) Every restriction has an implementation cost. There are only two ways to
+ implement this restriction that I can see, either strip all
+ implementation-defined identifiers from System (then the restriction is a
+ no-op) -- but that of course would break all code using those things. For
+ Janus/Ada, that would break virtually all existing uses of 'Address
+ (since they all are followed by .Offset, and it also would disallow use
+ of Offset_Type, the type of the numeric part of 'Address). The only other
+ possible implementation would be to put a bit into *every* symboltable
+ record to determine if it is subject to this restriction.
+
+ That's not that bad if there is only one restriction, but we've already got
+ several that will need such bits -- and those bits are all disjoint as each
+ restriction has to be individually enforceable. That means I can't share the
+ bits between No_Implementation_Units and this one (for instance). So as we
+ head down the slippery slope here, this will quickly turn into quite a bit
+ of extra memory on every symbol entry -- which means on every entity:
+ objects, parameters, components, subprograms, operators, packages,
+ everything. Yuck.
+
+This seems to me to be the kind of check that belongs in AdaControl; but I think
+you are doing it backwards. You "simply" have to have a list of the
+language-defined identifiers in System, and reject any use of any identifier
+referenced from System that isn't on the list. (OK, maybe that's not so simple,
+but it seems possible enough.) Then you'll only have to change the list of
+allowed identifiers when the Ada standard changes. Chasing implementation
+changes seems like a strategy which is guaranteed to lose.
+
+Besides, the most effective way to ensure you have portable Ada code is to buy a
+copy of Janus/Ada and compile it with it. If you can get it compile and run on
+both Janus/Ada and GNAT, you have code that is at least 98% portable -- since
+these compilers represent the ends of the spectrum of implementation choices.
+And that would catch a lot of runtime dependencies as well, as well as figure
+out which constructs are too buggy to depend on. But this takes too long for
+most people.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, February 11, 2011 2:58 AM
+
+>> I deliberately left out No_Implementation_Units, because Robert's
+>> e-mail seemed to make it clear that he's not asking for a standard
+>> feature. He's asking for an informal agreement that folks would
+>> implement this restriction.
+>
+> Robert doesn't have to ask for "informal agreement". He just has to do
+> it, and the rest of us will have to copy him. ;-)
+
+Exactly, not sure what that was about, but when I suggest something like that on
+the ARG list, I am definitely suggesting that eventually it be standardized.
+
+Yes, we can just go ahead and do things, but we try to discuss in advance when
+there are items that clearly might well be standardized
+
+> In any case, this seems to me like an odd omission from the existing
+> No_Implementation_xxx restrictions, and since we are adding a bunch of
+> other restrictions, we should fix this clear omission. If nobody else
+> agrees, that's fine with me.
+
+I agree :-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, February 11, 2011 3:01 AM
+
+May be there should be a
+
+pragma Profile (Portable);
+
+that encompasses all these portability related restrictions.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, February 11, 2011 3:02 AM
+
+Tucker Taft wrote:
+> I find it very annoying when people unintentionally use features of a
+> compiler that are non-standard, thereby making it harder to reuse
+> their code, especially when there is an equivalent standard way of
+> doing things. For example, using 'Unrestricted_Access when
+> 'Unchecked_Access (or even 'Access) would have worked fine.
+> Similarly, using Max_Priority rather than Priority'Last.
+
+I agree with Tuck on this point
+
+Randy Brukardt wrote:
+> ... It is interesting that this discussion has convinced me that the
+> No_Implementation_xxx restrictions are a waste of time, because they
+> don't do anything significant toward making Ada code portable. So now
+> I'm leaning Bob's way on this one.
+
+And I disagree with Randy (and perhaps Bob, but not sure that his viewpoint is
+so clear).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, February 11, 2011 3:04 AM
+
+> To do this right, you'd need a restriction for everything that is
+> marked unspecified or implementation-defined in the Standard. Annex M
+> has a list of more than 140 implementation-defined items. And then
+> there is implementation advice, unspecified, and the rest. Are we
+> going to add restrictions to cover all of them? And a significant
+> number of these things can't even be checked at compile-time.
+
+No reason whatever to recognize this bogus argument in my view.
+
+This argument goes like this
+
+If you add X you should also add Y, but it is obviously a bad idea to add Y, so
+you should not add X.
+
+We just consider things on a case by case basis and add only the ones that make
+sense and where we feel there is a problem,, and certainly we don't add things
+that can't be checked!!!
+
+> And then the question is whether people really are going to use all of
+> these restrictions. That seems doubtful as well.
+
+My pragma Profile (POrtable) would help there
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, February 11, 2011 3:00 AM
+
+> I suspect that if you suggest a reasonable name for the restriction,
+> GNAT folks might add support for it.
+
+Sure
+
+
+ Something like:
+>
+> pragma Restrictions(No_Nonstandard_System_Components);
+>
+> I don't really agree with Randy, since often the reason to use things
+> in System is specifically to achieve portability, such as using
+> System.Max_Int, or System.Default_Bit_Order. So it can be annoying
+> that there are seemingly useful declarations in package System that
+> are in fact not standard, and there is no obvious way of realizing
+> that without actually doing a line-by-line comparison with the version
+> of System in the reference manual.
+
+Well we don't add stuff to System for our amusement, buit because we see a
+genuine need, so the other way to react to such additions is to wonder whether
+to add them :-) :-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, February 11, 2011 3:05 AM
+
+> ...
+>>> For the analogous case of No_Dependence, we have "real" wording:
+>>> 13.12.1(7/2).
+>>
+>> The wording for No_Dependence is completely screwed up, IMHO, so I
+>> felt no obligation to follow that. The intent is clear enough, so I
+>> don't want to fix No_Dependence.
+>
+> "Completely screwed up"?? We spent a lot of time on that, and having
+> re-read it, it seems exactly correct to me. What am I missing?
+
+Seems fine to me too
+>
+> The only guess that I can even hazard is that you don't like the
+> reference to the syntactic "name" in this wording, but that is
+> standard practice for pragmas in the standard, and it doesn't
+> automatically carry any semantic meaning.
+>
+> I would expect to use virtually identical wording for the aspect case.
+>
+> I would agree that I don't want to fix No_Dependence, because it isn't
+> wrong. ;-)
+
+Yes, I see nothing to fix! And No_Dependence is definitely useful!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, February 11, 2011 3:09 AM
+
+> ...
+>> BTW, restrictions are nice, because they cause no harm: if you don't
+>> like a restriction, don't use it.
+>
+> No harm, maybe, but they're expensive for both users and implementers.
+
+The ones we are talking about are trivial to implement And I see no expense for
+users.
+
+> Two points which you may have missed:
+> (1) None of these restrictions are partition-wide, because the
+> runtime has to be able to depend on implementation-defined stuff. As
+> such, you'll have to repeat them in every compilation in your system.
+> Moreover, at this point there are 5 of these things (and you want to
+> add a 6th), so you have a block of 6 pragmas at the top of *every*
+> compilation unit. Can you say noise?? I'd rather use AdaControl
+> (really: it's too bad that it requires being able to compile a program
+> with GNAT before it can be used; that prevents using it on most Janus/Ada
+> code). I doubt many would do that.
+
+This is nonsense, in any reasonable technology, certainly in GNAT, it is
+perfectly easy to have project wide configuration pragmas. If there are
+compilers that are broken in this respect, fix them.
+
+> (2) Every restriction has an implementation cost. There are only
+> two ways to implement this restriction that I can see, either strip
+> all implementation-defined identifiers from System (then the
+> restriction is a
+> no-op) -- but that of course would break all code using those things.
+> For Janus/Ada, that would break virtually all existing uses of
+> 'Address (since they all are followed by .Offset, and it also would
+> disallow use of Offset_Type, the type of the numeric part of
+> 'Address). The only other possible implementation would be to put a
+> bit into *every* symboltable record to determine if it is subject to this
+> restriction.
+
+Right, and that is trivial to do
+
+> That's not that bad if there is only one restriction, but we've
+> already got several that will need such bits -- and those bits are all
+> disjoint as each restriction has to be individually enforceable. That
+> means I can't share the bits between No_Implementation_Units and this one (for instance).
+> So as we head down the slippery slope here, this will quickly turn
+> into quite a bit of extra memory on every symbol entry -- which means
+> on every
+> entity: objects, parameters, components, subprograms, operators,
+> packages, everything. Yuck.
+
+I think Randy is hugely overblowing the implementation difficulty
+
+...
+> Besides, the most effective way to ensure you have portable Ada code
+> is to buy a copy of Janus/Ada and compile it with it. If you can get
+> it compile and run on both Janus/Ada and GNAT, you have code that is
+> at least 98% portable -- since these compilers represent the ends of
+> the spectrum of implementation choices. And that would catch a lot of
+> runtime dependencies as well, as well as figure out which constructs are too
+> buggy to depend on. But this takes too long for most people.
+
+Well I doubt this is a serious suggestion, it is certainly impractical!
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, February 11, 2011 7:40 AM
+
+They cause little-or-no harm to programmers.
+
+They can cause implementation difficulty, though, which is an indirect harm to
+programmers.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, February 11, 2011 7:40 AM
+
+Probably a good idea, but I don't like the name Portable, because it doesn't
+come close to guaranteeing portability.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, February 11, 2011 7:40 AM
+
+> Just so there's no confusion here, I wasn't referring to "Priority'Last"
+> being non-portable (even though it will differ between implementations).
+> I was referring to System.Max_Priority, which is not defined by the
+> language, but apparently is added by GNAT.
+
+Understood. I understand the point you and Tucker are making, and I agree with
+it.
+
+But I took your Max_Priority as just one example of a larger category of "things
+that cause gratuitous nonportability". Not sure exactly what that means. Maybe
+you meant just things in System, or maybe you meant things in any
+language-defined package (Randy mentioned Queues.Implementation.*).
+
+> This isn't just a hypothetical potential problem.
+> A week or two ago, Brad Moore stumbled into this exact problem when he
+> posted his "Paraffin" code, which unintentionally used
+> System.Max_Priority rather than Priority'Last.
+
+Yes, I don't question the fact that it's a real problem.
+I've seen it myself.
+
+The way I've addressed it in the past is to compile my supposedly portable code
+on a variety of Ada compilers. That's of course not a complete solution, but it
+helps.
+
+> Given that portability is a major goal of Ada, I think that the
+> easy-to-fix portability problems deserve serious consideration, even
+> if hard-to-fix problems remain.
+
+"Easy to fix" is what I'm questioning. If somebody comes up with exact RM
+wording describing precisely what is forbidden by the proposed restriction, AND
+it looks reasonably easy to implement it, then I could support it.
+
+Robert says it's trivial, but I won't believe that until I understand exactly
+what is being proposed.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, February 11, 2011 11:52 AM
+
+> I'd rather use AdaControl (really: it's too bad that it requires being
+> able to compile a program with GNAT before it can be used; that
+> prevents using it on most Janus/Ada code).
+
+Actually, I have clients who use other compilers; the AdaControl installation
+hides a Gnat inside it. But I would be delighted to provide an
+AdaControl-for-Janus; as soon as your implementation of ASIS is ready ;-)
+
+> This seems to me to be the kind of check that belongs in AdaControl;
+> but I think you are doing it backwards. You "simply" have to have a
+> list of the language-defined identifiers in System, and reject any use
+> of any identifier referenced from System that isn't on the list. (OK,
+> maybe that's not so simple, but it seems possible enough.)
+
+I understand your point, but I have an existing rule to check occurrences of any
+entity, so doing it this way iq possible without any further development. Doing
+it the other way is quite doable, but it would be a new rule, and an ad-hoc one.
+This kind or rule goes to a special slot in my todo list: "wait till a customer
+is willing to pay for the rule".
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Friday, February 11, 2011 12:06 PM
+
+> Well we don't add stuff to System for our amusement, buit because we
+> see a genuine need, so the other way to react to such additions is to
+> wonder whether to add them :-) :-)
+
+I would be interested to know that the genuine need was for System.Max_Priority.
+It looks to me like a savings of just one character from System.Priority'last.
+This is the only implementation-defined System name that I can recall bumping
+into recently (there were of course things like System.No_Address in Ada 83
+compilers), so I don't see it as the tip of an iceberg.
+
+I think the users who want to avoid implementation-defined System names are the
+same users who want to avoid the other implementation-defined portability
+concerns, so I am happy if this restriction simply piggy-backs on the
+restriction for no implementation-defined units.
+
+It is interesting that RM 13.7(36/2) says:
+
+"An implementation may add additional implementation-defined declarations to
+package System and its children. However, it is usually better for the
+implementation to provide additional functionality via implementation-defined
+children of System."
+
+The second sentence might be better moved under the following "Implementation
+Advice" header, so implementations that "pollute the System name space" so to
+speak, will be seen as going against Implementation Advice.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 11, 2011 12:45 PM
+
+...
+> > No harm, maybe, but they're expensive for both users and implementers.
+>
+> The ones we are talking about are trivial to implement And I see no
+> expense for users.
+
+I'm not claiming that these are hard to implement in a vacuum, but rather that
+doing so is time-consuming. Each and every restriction takes a day or more to
+implement: add some bits to represent the presence of the restriction, ensure
+they get initialized properly, add some bits or a query to detect the
+restriction, figure out where the restriction has to be enforced, add error
+messages. On top of that, the vast majority of restrictions have to be enforced
+as post-compilation checks, so those bits also have to be added to the object
+code format and the binder has to be updated to check them.
+
+In addition, there ought to be ACATS tests (although these are untestable).
+
+And we're talking about quite a few restrictions here, so this gets multiplied.
+
+Maybe if your organization has 30 developers only working on Ada compilers these
+costs aren't significant. But they surely are to RRS. And I'd rather spend the
+effect on something that *adds* functionality rather than something that is more
+of a style check. Generally, we leave style concerns to external tools like
+AdaControl, it's not clear to me why we would want to be different here.
+
+...
+> > Besides, the most effective way to ensure you have portable Ada code
+> > is to buy a copy of Janus/Ada and compile it with it. If you can get
+> > it compile and run on both Janus/Ada and GNAT, you have code that is
+> > at least 98% portable -- since these compilers represent the ends of
+> > the spectrum of implementation choices. And that would catch a lot
+> > of runtime dependencies as well, as well as figure out which
+> > constructs are too buggy to depend on. But this takes too long for
+> > most people.
+>
+> Well I doubt this is a serious suggestion, it is certainly
+> impractical!
+
+Of course it is a serious suggestion; every bit of "portable" code that I've
+ever been associated with has been compiled through *at least* Janus/Ada and
+GNAT. I wouldn't think of claiming that code was portable if I hadn't done that.
+Claw was regularly compiled through 4 different compilers when it was being
+actively developed (can't use the Rationale one anymore, unfortunately).
+
+If your target isn't supported by more than one Ada compiler, and retargetting
+isn't practical, there isn't any point in even worrying about portable code --
+it's not portable in any event.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 11, 2011 12:46 PM
+
+> > May be there should be a
+> >
+> > pragma Profile (Portable);
+> >
+> > that encompasses all these portability related restrictions.
+>
+> Probably a good idea, but I don't like the name Portable, because it
+> doesn't come close to guaranteeing portability.
+
+I agree with Bob: both parts.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, February 11, 2011 11:36 AM
+
+...
+> But I took your Max_Priority as just one example of a larger category
+> of "things that cause gratuitous nonportability".
+> Not sure exactly what that means. Maybe you meant just things in
+> System, or maybe you meant things in any language-defined package
+> (Randy mentioned Queues.Implementation.*).
+
+I am not as much concerned about the portability of the number of bits in
+Integer. I think programmers who want to write portable code will generally be
+aware of the portability issues of using Integer, it's a problem that C
+programmers (at least some of them) also understand.
+
+I'm more concerned about using non-language defined items that are declared in
+language defined packages. Those sorts of portability issues are a trap that I
+think is easier to fall into unaware.
+
+>> This isn't just a hypothetical potential problem.
+>> A week or two ago, Brad Moore stumbled into this exact problem when
+>> he posted his "Paraffin" code, which unintentionally used
+>> System.Max_Priority rather than Priority'Last.
+> Yes, I don't question the fact that it's a real problem.
+> I've seen it myself.
+>
+> The way I've addressed it in the past is to compile my supposedly
+> portable code on a variety of Ada compilers.
+> That's of course not a complete solution, but it helps.
+
+Not everyone has a budget that would allow purchasing a variety of Ada
+compilers, nor is it practical for everyone test their code on this variety of
+Ada compilers.
+
+Developers creating packages for general use, would appreciate a higher level of
+confidence that their code is portable.
+
+ A pragma (Portable) sounds like a great idea to me.
+
+It wouldn't have to be perfect, just like pragma Optimize (Time) doesn't
+guarantee that your program will be fast.
+
+Perhaps it could be treated as advice to the implementation that portability is
+desired, and the implementation could make some attempt to flag potential
+portability problems.
+
+It would also provide documentation to other developers on the project that
+portability is a desired attribute, and that they should write their code with
+an eye to portability.
+
+A compiler that uses 32 bit integers maybe would not have as much need to worry
+about integer size portability, whereas a compiler using a 16 bit integer
+probably should make an attempt to flag integer size portability potential
+pitfalls.
+
+Perhaps the easiest ones to catch (or common pitfalls) such as
+System.Max_Priority could be identified in the AARM as implementation advice for
+the portable pragma.
+
+Regarding Integer size portability, it would be nice if the pragma could
+potentially disallow the use of unconstrained scalar types. eg.
+
+ type Integer_32 is range -2 ** 31 .. 2 ** 31 - 1;
+
+type foo is new Integer; -- Disallowed
+type bar is new Integer_32; -- Allowed
+
+I think defining portability in terms of a restriction would need to be more
+defined, and strive for a higher level of portability assurance, which would be
+great for users, but that might be more difficult to define and implement.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, February 11, 2011 4:28 PM
+
+> > The wording for No_Dependence is completely screwed up, IMHO, so I
+> > felt no obligation to follow that. The intent is clear enough, so I
+> > don't want to fix No_Dependence.
+>
+> "Completely screwed up"?? We spent a lot of time on that, and having
+> re-read it, it seems exactly correct to me. What am I missing?
+
+Spending time /= correct. ;-)
+
+Sorry, I'm not intending to tread on anyone's toes, here; "completely screwed
+up" is perhaps exaggeration. As I said, the intent is clear. I don't want to
+change it, I'm just saying I don't want to use it as a model of perfection to be
+copied verbatim by No_Aspect_Spec.
+
+> The only guess that I can even hazard is that you don't like the
+> reference to the syntactic "name" in this wording,...
+
+Yes, that's the root of what I was referring to. In Ada 95, we were (I think)
+careful to distinguish "name" from "identifier". A "name" is resolved, and
+denotes something -- visibility rules apply. When you say "end Foo;" no
+visibility rules apply to Foo, and it doesn't denote anything.
+
+>...but that is standard practice for
+> pragmas in the standard, and it doesn't automatically carry any
+>semantic meaning.
+
+Pragmas are a special case, because there's a general syntax for them, but each
+one also has it's own syntax. I think we were careful to use "identifier" for
+pragma arguments that are not resolved.
+
+We have:
+
+ restriction_parameter_argument ::= name | expression
+
+And I'm saying that for No_Aspect_Specification, it should really be:
+
+ restriction_parameter_argument ::= name | expression | identifier
+
+And to handler No_Dependence properly, it should be something like:
+
+ restriction_parameter_argument ::= name | expression | dotted_identifiers
+ dotted_identifiers ::= identifier {. identifier}
+
+> I would expect to use virtually identical wording for the aspect case.
+
+No_Dependence says "...need not denote a unit present in the environment". That
+makes no sense (with my language lawyer hat on). It DOES not denote anything at
+all. No visibility rules even apply. And "the environment" has nothing to do
+with it.
+
+> I would agree that I don't want to fix No_Dependence, because it isn't
+> wrong. ;-)
+
+We agree on the conclusion (don't fix No_Dependence), if not the reasons.
+I'm just saying, the wording for No_Dependence is dubious, formally, so don't
+beat me up about the fact that No_Aspect_Specification wording is dubious.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 11, 2011 11:06 PM
+
+> May be there should be a
+>
+> pragma Profile (Portable);
+>
+> that encompasses all these portability related restrictions.
+
+I think this is a good idea (I tried to suggest something like it yesterday in
+one of my rambling messages) -- but for Ada 2020.
+
+At this point, we can only really add things to Ada 2012 that are clearly
+omissions, have clear rules, and are non-controversial. If it is going to take
+more than 5 minutes of ARG time to discuss, it is a non-starter. Restriction
+No_Implementation_Units meets the criteria; the rule is simple, the omission
+clear. It should take just a couple of minutes discussion and an up or down
+vote. If it goes beyond that, I think it should automatically be killed.
+
+OTOH, it's clear that exactly what should be in this profile is going to require
+some discussion, and in particular whether there should be additional
+restrictions defined and included in this profile. That would take time away
+from our other work, most of which is far more important. So I don't think we
+should be considering anything else now.
+
+(You're welcome to talk about Ada 2020 stuff of course, but please make a
+separate thread so I don't need to file it with the Ada 2012 AIs...)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 11, 2011 11:50 PM
+
+> I am not as much concerned about the portability of the number of bits
+> in Integer. I think programmers who want to write portable code will
+> generally be aware of the portability issues of using Integer, it's a
+> problem that C programmers (at least some of them) also understand.
+
+I wanted to give this topic a rest, but I had to answer this statement.
+
+In my experience (with an Ada compiler that uses a 16-bit Integer type),
+virtually no Ada programmers are aware that Integer is not necessarily 32-bit.
+The vast majority of the supposedly portable public domain and open source code
+that we've tried to compile over the years have fallen over for this reason,
+long before we reach any thing about implementation defined units or attributes.
+That's been true from the earliest days of Ada 83 until the present (a recent
+bug report starts: "I tried to compile <<Brand-new open source code>>. There are
+of course a few places he assumes32 bit integers, and ...").
+
+You would think that Ada programmer's would be aware of this possible problem
+(and more so than C programmers), but the reverse seems to be true (or perhaps
+no one is aware of it).
+
+The portability problems that I see tend to be:
+ (1) Assuming that Integer is 32-bit (at least 75% of programs);
+ (2) Assuming that an access value and System.Address are the same size
+ and that Unchecked_Conversion works between them (>20% of programs,
+ even though Address_to_Access_Conversions safely provides the
+ needed functionality);
+ (3) Use of implementation-defined attributes (>10% of programs).
+
+The last is covered by the Ada 2005 restriction (but I have yet to see anyone
+use it in code). The other two aren't covered by any proposal. I haven't seen
+much accidental use of implementation-defined packages -- Gnat has done a good
+thing here making it clear which ones those are. (I've seen a lot of intentional
+use of such packages, but if the author doesn't claim portability, that isn't
+really a problem; they wouldn't be a candidate for using the restrictions and/or
+profile anyway.)
+
+So I don't think that anything proposed would do much to make Ada code more
+portable, at least to Janus/Ada from other compilers. Which is why I have to
+wonder about the value...
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, February 12, 2011 7:40 AM
+
+> So I don't think that anything proposed would do much to make Ada code
+> more portable, at least to Janus/Ada from other compilers. Which is
+> why I have to wonder about the value...
+
+I agree that for Janus/Ada, if you have made the (very unwise in my
+opinion) decision to make integer 16-bit (*) then no wonder you have major
+portability problems, and blaming Ada programmers is not really the right
+response. Indeed in such a situation these aspect related restrictions will not
+help much, but these restrictions are not about helping people port to
+Janus/Ada. They are more about making sure that people who write Ada code do not
+unwittingly use aspects etc defined in GNAT that are not in the standard if they
+want to maintain compatibility with possible future versions of compilers from
+other vendors.
+
+GNAT will go ahead and implement these anyway I suspect, but we always prefer to
+follow a guidance from the standard where the standard is willing to give such
+guidance.
+
+(*) in my opinion, the Ada 95 standard should have specified 32-bits as a
+MINIMUM for type Integer, an implementation using 16-bits should not be
+considered to be standard, but I know the history here. In practice all Ada
+compilers other than Janus/Ada will choose 32-bits on 32-bit architectures, so
+it does not make that much difference for the standard to have the completely
+idiotic statement:
+
+> 21 In an implementation, the range of Integer shall include the range
+> -2**15+1 .. +2**15-1.
+
+Idiotic because it would be better to omit this than make a statement which
+
+a) does not actually constrain implementations at all, no one would even
+ consider integer less than 16 bits.
+
+b) encourages and legitimizes the bad choice of 16-bits for type Integer
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, February 12, 2011 8:06 AM
+
+> I agree that for Janus/Ada, if you have made the (very unwise in my
+> opinion) decision to make integer 16-bit (*)...
+
+That compiler comes from 8086, I believe, on which limiting Strings to 32K (and
+therefore making Standard.Integer 16 bits) is pretty reasonable. Doubling the
+size of String dope on such a limited-memory machine would be unwise. And
+keeping it that way on 80386 made sense for compatibility (although I tend to
+agree that 16 bits is really too small for 80386).
+
+Low-end embedded systems still use machines with small address spaces, and no
+doubt will do so forever, so small Integer still makes sense today, on some
+machines. I'd like to see Ada compete with C on such machines, and insisting on
+inefficiency won't help.
+
+Intermetrics wrote an Ada compiler for some weird 24-bit computer, and it would
+have been ridiculous to make Integer 48 bits. This was in the late 1990's. It's
+probably still in use (I don't know).
+
+>... then no wonder you have
+> major portability problems, and blaming Ada programmers is not really
+>the right response.
+
+Well, I think both compiler writers and programmers should be able to rely on
+the contract that is the RM, without asking Robert Dewar's opinion of what's a
+reasonable size for Integer. Especially when Bob Duff's opinion differs. I'm
+not trying to convince you 16-bit Integer is OK -- I'm merely stating the fact
+that some people think so.
+
+>...Indeed in such a situation these aspect related restrictions will
+>not help much, but these restrictions are not about helping people
+>port to Janus/Ada. They are more about making sure that people who
+>write Ada code do not unwittingly use aspects etc defined in GNAT that
+>are not in the standard if they want to maintain compatibility with
+>possible future versions of compilers from other vendors.
+
+Well, I haven't seen a proposal that addresses Dan's concern about
+System.Max_Priority. Just a lot of people insisting it's a real concern. And
+nobody who has expressed an opinion has disagreed with that!
+
+As I said, if I see a concrete proposal that's easy to implement, I might
+support it.
+
+I would also support profile Portable if somebody can think of a better name --
+I tried and failed. I think I understand the semantics -- it's the combination
+of all the No_Implemention_* restrictions that exist.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, February 12, 2011 8:10 AM
+
+> The way I've addressed it in the past is to compile my supposedly
+> portable code on a variety of Ada compilers.
+> That's of course not a complete solution, but it helps.
+
+It is a HUGE effort to compile a large program on a "variety of Ada compilers",
+yes, it's easy to compile a couple of packages, but keeping a large source base
+in a form where it can be compiled on multiple compilers, not to mention
+acquiring and installing the compilers, is a big undertaking.
+
+For instance, when using GNAT, large programs typically come with a large and
+often quite complex project file, describing where all the sources are, what the
+naming conventions are, what options are to be used in compiling them etc.
+Porting the Ada code is just one element of porting a system to another
+compiler, you also have to port the project file.
+
+>> Given that portability is a major goal of Ada, I think that the
+>> easy-to-fix portability problems deserve serious consideration, even
+>> if hard-to-fix problems remain.
+>
+> "Easy to fix" is what I'm questioning. If somebody comes up with
+> exact RM wording describing precisely what is forbidden by the
+> proposed restriction, AND it looks reasonably easy to implement it,
+> then I could support it.
+>
+> Robert says it's trivial, but I won't believe that until I understand
+> exactly what is being proposed.
+
+I am labeling as trivial the specific proposals that have been made (not the
+giant amorphous extension proposed by Bob!) Indeed I don't think we should
+consider anythinng that is NOT easy to implement.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, February 12, 2011 8:11 AM
+
+> They can cause implementation difficulty, though, which is an indirect
+> harm to programmers.
+
+None of the restrictions proposed so far cause implementaiton difficulty. I
+would just implement them this afternoon if we agreed on what they were :-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, February 12, 2011 8:12 AM
+
+>> May be there should be a
+>>
+>> pragma Profile (Portable);
+>>
+>> that encompasses all these portability related restrictions.
+>
+> Probably a good idea, but I don't like the name Portable, because it
+> doesn't come close to guaranteeing portability.
+
+Who said that it DID guarantee portability, that's obviously impossible, so
+anyone who thinks it can do so is seriously misguided anyway. But alternative
+names are welcome if not ludicrously long!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, February 12, 2011 8:15 AM
+
+> I'm more concerned about using non-language defined items that are
+> declared in language defined packages.
+> Those sorts of portability issues are a trap that I think is easier to
+> fall into unaware.
+
+I agree
+
+> A pragma (Portable) sounds like a great idea to me.
+>
+> It wouldn't have to be perfect, just like pragma Optimize (Time)
+> doesn't guarantee that your program will be fast.
+
+Good analogy, I really like the name Portable, I don't mind some alternative if
+it is not too weird, but I think Portable catches the intent perfectly.
+
+> Perhaps it could be treated as advice to the implementation that
+> portability is desired, and the implementation could make some attempt
+> to flag potential portability problems.
+
+Well I don't like that, a profile should be a set of well defined restrictions
+
+> Perhaps the easiest ones to catch (or common pitfalls) such as
+> System.Max_Priority could be identified in the AARM as implementation
+> advice for the portable pragma.
+
+Ah, you are thinking of
+
+ pragma Portable;
+
+rather than
+
+ pragma Profile (Portable);
+
+well that indeed might make sense
+
+> Regarding Integer size portability, it would be nice if the pragma
+> could potentially disallow the use of unconstrained scalar types.
+
+Please NO, this has nothing to do with portability per se, let's not get this
+thing entangled with style stuff!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, February 12, 2011 8:33 AM
+
+> The second sentence might be better moved under the following
+> "Implementation Advice" header, so implementations that "pollute the System
+> name space" so to speak, will be seen as going against Implementation Advice.
+
+I agree!
+
+(and note this would also require documentation in Annex M)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, February 12, 2011 8:42 AM
+
+> I'm not claiming that these are hard to implement in a vacuum, but
+> rather that doing so is time-consuming. Each and every restriction
+> takes a day or more to implement: add some bits to represent the
+> presence of the restriction, ensure they get initialized properly, add
+> some bits or a query to detect the restriction, figure out where the
+> restriction has to be enforced, add error messages. On top of that,
+> the vast majority of restrictions have to be enforced as
+> post-compilation checks, so those bits also have to be added to the
+> object code format and the binder has to be updated to check them.
+
+Well I can't speak to the difficulties of doing stuff in Janus (which often seem
+a bit extreme to me), but I can say that these are very easy to implement in
+GNAT. Since we are only talking about Ada 2012 implementations, we can safetly
+say that for now, implementing aspect related restrictions is easy in all
+implementions implementing aspects!
+
+Seriously, if you are worried about the difficulty of implementing these
+restrictions, I would predict that you will never get all of the aspect stuff
+implemented at all (it's REALLY tough, and that is speaking from experience).
+
+> Of course it is a serious suggestion; every bit of "portable" code
+> that I've ever been associated with has been compiled through *at
+> least* Janus/Ada and GNAT. I wouldn't think of claiming that code was
+> portable if I hadn't done that. Claw was regularly compiled through 4
+> different compilers when it was being actively developed (can't use
+> the Rationale one anymore, unfortunately).
+
+Until Janus/Ada can at the minimum handle GNAT project files, trying to compile
+a large GNAT code base on Janus/Ada will involve too much work. Also we are
+talking about aspect-related restrictions here, so the suggestion of using
+multiple compilers only works if we have multiple Ada 2012 compilers. I would be
+delighted to hear that we do, but until we do, the point can most certainly be
+left moot IMO.
+
+> If your target isn't supported by more than one Ada compiler, and
+> retargetting isn't practical, there isn't any point in even worrying
+> about portable code -- it's not portable in any event.
+
+But I don't buy that. I can see an organization deciding that they want to use
+Ada 2012 stuff, but stay away from GNAT extensions precisely because at some
+point in the future if there are other Ada 2012 compilers that will ease
+possible porting of the code, not to mention that there is an appeal in keeping
+the code well defined according to the standard.
+
+In practice, GNAT tries to implement everything from other compilers (e.g. all
+the DEC pragmas and attributes), but historically other Ada compilers have NOT
+made this attempt (Greenhills for instance is much "purer" Ada 95 than GNAT and
+does not add bells and whistles nearly so much).
+
+The bells and whistles are often very helpful, especially when porting code TO
+gnat, but I definitely see that some people may want to avoid using them.
+
+After all, it was me who originall proposed
+
+No_Implementation_Pragmas
+No_Implementation_Attributes
+No_Implementation_Restrictions
+
+and impleemented them!
+
+The last one was funny, it had to exclude itself when first implemented as an
+implementation restriction :-)
+
+and implemented them (the
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, February 12, 2011 8:43 AM
+
+>> Well we don't add stuff to System for our amusement, buit because we
+>> see a genuine need, so the other way to react to such additions is to
+>> wonder whether to add them :-) :-)
+>
+> I would be interested to know that the genuine need was for
+> System.Max_Priority. It looks to me like a savings of just one
+> character from System.Priority'last.
+
+Obviously it was not done just to save a character :-) At this stage I am not
+sure why we put it in, would require some archeology.
+
+Sometimes we put this sort of thing in from staticness considerations, but I
+don't think that's the issue here, though looking 71 different versions of this
+file for 71 different configurations is not an easy task.
+
+Sometimes we do this because some other implementation has done it, we try to
+track all such stuff in other compilers and implement it (we are more interested
+in people being easily able to port *TO* GNAT than *FROM* GNAT for obvious
+reasons.
+
+Perhaps the reason is now OBE?
+
+Perhaps there is some other real reason which I have not uncovered, but in any
+case the reason for the existence of this declaration and its relation to
+System.Priority'Last should be documented clearly, so I opened an internal
+ticket for that requirement.
+
+Of course at this stage, it can't be removed because of backwards compatibility
+considerations.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, February 12, 2011 8:44 AM
+
+>> I would agree that I don't want to fix No_Dependence, because it
+>> isn't wrong. ;-)
+>
+> We agree on the conclusion (don't fix No_Dependence), if not the reasons.
+> I'm just saying, the wording for No_Dependence is dubious, formally,
+> so don't beat me up about the fact that No_Aspect_Specification
+> wording is dubious.
+
+Who cares? Not me, at least not much. It's fine to worry about delicacies of
+wording in the RM for things that are clear and obvious, but not to spend TOO
+much time on such worrying!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, February 12, 2011 8:47 AM
+
+>> May be there should be a
+>>
+>> pragma Profile (Portable);
+>>
+>> that encompasses all these portability related restrictions.
+>
+> I think this is a good idea (I tried to suggest something like it
+> yesterday in one of my rambling messages) -- but for Ada 2020.
+>
+> At this point, we can only really add things to Ada 2012 that are
+> clearly omissions, have clear rules, and are non-controversial. If it
+> is going to take more than 5 minutes of ARG time to discuss, it is a non-starter.
+> Restriction No_Implementation_Units meets the criteria; the rule is
+> simple, the omission clear. It should take just a couple of minutes
+> discussion and an up or down vote. If it goes beyond that, I think it
+> should automatically be killed.
+
+No_Implemntation_Aspects should *really* *really* be there, it's obviously
+useful and consistent with No_Implementation_Restrictions etc.
+
+Personally I think it should JUST refer to aspects, and not to related pragmas
+etc, the latter gets too confusing, and is taken care of by
+No_Implementation_Pragmas, and No_Implementation_Attributes.
+
+So VERY simple clear definition
+
+pragma Restrictions (No_Implementation_Aspects);
+
+the program shall not use aspect names in an Aspect definition clause which are
+not defined by the standard.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, February 12, 2011 8:50 AM
+
+> > The way I've addressed it in the past is to compile my supposedly
+> > portable code on a variety of Ada compilers.
+> > That's of course not a complete solution, but it helps.
+>
+> It is a HUGE effort to compile a large program on a "variety of Ada
+> compilers", ...
+
+It's really not that hard, if you decide from the start that you want
+portability, and set it up at the beginning of your project. CodePeer is an
+example. Build and test on multiple compilers every day, and you can easily fix
+portability problems.
+
+And anyway, if you don't do that, it won't be portable, no matter what
+pragmas/restrictions you use.
+
+>... yes, it's easy to compile a couple of packages, but keeping a
+>large source base in a form where it can be compiled on multiple
+>compilers, not to mention acquiring and installing the compilers, is a
+>big undertaking.
+
+Yes, acquiring compilers can be expensive for a hobbyist.
+For a large industrial-strength project, not so much.
+
+Installing them? A bit of a pain, but no big deal.
+
+> For instance, when using GNAT, large programs typically come with a
+> large and often quite complex project file, describing where all the
+> sources are, what the naming conventions are, what options are to be
+> used in compiling them etc. Porting the Ada code is just one element
+> of porting a system to another compiler, you also have to port the
+> project file.
+
+CodePeer has hundreds of thousands of lines of Ada code.
+The part that differs across compilers and platforms is in the hundreds of
+lines, IIRC, including build scripts such as project files.
+
+Anybody who has project files that are a subtantial fraction of the total code
+size is doing it wrong.
+
+Of course, if you don't do it from the start, porting is a huge job.
+
+> I am labeling as trivial the specific proposals that have been made
+> ...
+
+No proposal has been made that addresses Dan's concern about
+System.Max_Priority, so you cannot possibly claim such a nonexistent proposal is
+trivial.
+
+>...(not the giant amorphous extension proposed by
+> Bob!)
+
+I didn't propose anything. I'm just trying to find out what the proposal is,
+and it's frustrating that people keep insisting that it's important, and that
+it's trivial to implement, without telling me what is proposed!
+
+>... Indeed I don't think we should consider anythinng that is NOT easy
+>to implement.
+
+Agreed. Now please, somebody tell me what you and Dan and Tucker and Brad are
+proposing.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, February 12, 2011 9:13 AM
+
+> Yes, acquiring compilers can be expensive for a hobbyist.
+> For a large industrial-strength project, not so much.
+
+It is a HUGE effort to acquire a compiler
+
+> Installing them? A bit of a pain, but no big deal.
+
+You must be joking, I think you are just completely oblivious of the real
+difficulties. Getting a compiler installed often involves numerous steps
+
+a) approval by intermediate management
+b) negotation of terms by purchasing
+c) actual acquisition
+d) qualifiction by IT department
+e) installation by IT department (often WAY backed up)
+f) training of people in using the compiler
+
+etc
+
+technical people often fail to understand that TCO is a huge multiple of basic
+cost!
+
+>> For instance, when using GNAT, large programs typically come with a
+>> large and often quite complex project file, describing where all the
+>> sources are, what the naming conventions are, what options are to be
+>> used in compiling them etc. Porting the Ada code is just one element
+>> of porting a system to another compiler, you also have to port the
+>> project file.
+>
+> CodePeer has hundreds of thousands of lines of Ada code.
+> The part that differs across compilers and platforms is in the
+> hundreds of lines, IIRC, including build scripts such as project
+> files.
+>
+> Anybody who has project files that are a subtantial fraction of the
+> total code size is doing it wrong.
+
+Have you ever LOOKED at the project files for large projects? I bet the answer
+is no.
+
+> Of course, if you don't do it from the start, porting is a huge job.
+>
+>> I am labeling as trivial the specific proposals that have been made
+>> ...
+>
+> No proposal has been made that addresses Dan's concern about
+> System.Max_Priority, so you cannot possibly claim such a nonexistent
+> proposal is trivial.
+
+To me, the proposal that was made was use of impl added declarations in package
+System. If you want to extend this to other packages defined in the standard
+that's trivial too.
+
+>> ...(not the giant amorphous extension proposed by
+>> Bob!)
+>
+> I didn't propose anything. I'm just trying to find out what the
+> proposal is, and it's frustrating that people keep insisting that it's
+> important, and that it's trivial to implement, without telling me what
+> is proposed!
+>
+>> ... Indeed I don't think we should consider anythinng that is NOT
+>> easy to implement.
+>
+> Agreed. Now please, somebody tell me what you and Dan and Tucker and
+> Brad are proposing.
+
+I just did!
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, February 12, 2011 9:43 AM
+
+> Who cares? Not me, at least not much. It's fine to worry about
+> delicacies of wording in the RM for things that are clear and obvious,
+> but not to spend TOO much time on such worrying!
+
+I'm not sure you realize it, but you are agreeing with me!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, February 12, 2011 11:10 AM
+
+> I'm not sure you realize it, but you are agreeing with me!
+
+Yes, of course, and disagreeing with Randy! You are not >>> in the above, you
+are >>>>
+
+:-)
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Saturday, February 12, 2011 11:37 AM
+
+> I would also support profile Portable if somebody can think of a
+> better name -- I tried and failed.
+I am slightly uneasy with the name Portable, because I'm afraid users will think it promises much more than what we intend.
+
+profile (Strict_Standard)
+
+profile (No_Implementation_Extensions)
+(since it covers various No_Implementation_* restrictions)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, February 12, 2011 11:58 AM
+
+> profile (No_Implementation_Extensions)
+
+I suppose I could live with that one. Reluctantly.
+Better than anything I thought of (such as No_Implementation_Stuff,
+No_Implementation_Gizmos).
+
+Much better than Portable, which I'm strongly opposed to.
+I don't really buy the analogy with Optimize -- everybody knows that compiler
+folks misuse the term "optimize" to mean "make better" rather than "make
+optimal". But if somebody says, "this code is portable", I take it as a pretty
+strong claim.
+
+To use the term Portable, I'd want it to come very close to guaranteeing
+portability. (I wouldn't insist on 100%, though -- I mean, anything can raise
+Storage_Error, so nothing is 100% portable in theory.)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, February 12, 2011 12:17 PM
+
+>> profile (No_Implementation_Extensions)
+
+I can live with this, not as nice or convenient as portable, but livable, and if
+we have to have this name to get Bob happy, that's OK with me.
+
+One nice thing about this name is if it meant precisely
+
+ pragma Restrictions (No_Implementation_*)
+
+
+>
+> I suppose I could live with that one. Reluctantly.
+> Better than anything I thought of (such as No_Implementation_Stuff,
+> No_Implementation_Gizmos).
+>
+> Much better than Portable, which I'm strongly opposed to.
+> I don't really buy the analogy with Optimize -- everybody knows that
+> compiler folks misuse the term "optimize"
+> to mean "make better" rather than "make optimal".
+> But if somebody says, "this code is portable", I take it as a pretty
+> strong claim.
+
+You shouldn't! Not if you think portable means it is guaranteed to run with the
+same behavior on another compiler. Essentially no code is portable in this
+sense.
+
+> To use the term Portable, I'd want it to come very close to
+> guaranteeing portability. (I wouldn't insist on 100%, though -- I
+> mean, anything can raise Storage_Error, so nothing is 100% portable in
+> theory.)
+
+Plus floating-point, capacity issues, representation issues etc.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, February 12, 2011 8:19 PM
+
+...
+> > At this point, we can only really add things to Ada 2012 that are
+> > clearly omissions, have clear rules, and are non-controversial. If
+> > it is going to take more than 5 minutes of ARG time to discuss, it
+> > is a non-starter.
+> > Restriction No_Implementation_Units meets the criteria; the rule is
+> > simple, the omission clear. It should take just a couple of minutes
+> > discussion and an up or down vote. If it goes beyond that, I think
+> > it should automatically be killed.
+>
+> No_Implemntation_Aspects should *really* *really* be there, it's
+> obviously useful and consistent with No_Implementation_Restrictions
+> etc.
+
+Sorry, the subject of this thread is misleading. It's really about AI05-0242-1,
+restrictions beyond No_Implementation_Aspects.
+
+I have no problem with either of the restrictions proposed in AI05-0241-1; they
+both seem necessary based on other AIs and have no definitional issues. We
+haven't been talking about them all week.
+
+The question I raised was what, if any, additional restrictions to add to Ada
+2012. The only one that seems to meet the bar at this time (IMHO) is
+No_Implementation_Units. I split that topic into a separate AI (AI05-0242-1)
+when it started getting controversial, but the subject line never was changed.
+Sorry about any confusion.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, February 12, 2011 8:41 PM
+
+...
+> Well I can't speak to the difficulties of doing stuff in Janus (which
+> often seem a bit extreme to me), but I can say that these are very
+> easy to implement in GNAT. Since we are only talking about Ada 2012
+> implementations, we can safetly say that for now, implementing aspect
+> related restrictions is easy in all implementions implementing
+> aspects!
+>
+> Seriously, if you are worried about the difficulty of implementing
+> these restrictions, I would predict that you will never get all of the
+> aspect stuff implemented at all (it's REALLY tough, and that is
+> speaking from experience).
+
+Well, I'd rather spend the effort on aspects than on restrictions.
+
+I have thought about implementing aspect clauses in Janus/Ada, and I haven't
+identified anything particularly tough. (Probably Default_Value will be the
+hardest.) What I have noticed is that there are a lot of things that will need
+to be implemented, defined, and in some cases changed. So it will take a
+significant amount of effort even without any tough parts. (And because our
+syntax-directed compiler accesses everything off of a parse stack, counting from
+the top -- which is the right in productions -- adding syntax on the right end
+of entities changes a lot of the references to other entities in the code. So it
+is annoying simply because a lot of stuff that isn't related will need some
+changes.)
+
+Still, it doesn't seem anywhere near as bad as limited with or build-in-place
+functions or interfaces. Those look like disasters in waiting... (Or for that
+matter, the memory management overhaul that I'm currently working on when I am
+not spending time filing ARG mail. :-)
+
+What is really tough is getting ARG consensus and then getting wording to
+reflect that consensus. Compiler development of all kinds seems easy in
+comparison!! :-) :-)
+
+****************************************************************
Questions? Ask the ACAA Technical Agent