Version 1.4 of ai05s/ai05-0242-1.txt

No_Implementation_Pragmas

There are no implementation-defined pragmas or pragma arguments. This restriction applies only to the current compilation or environment, not the entire partition.

No_Implementation_Units

There is no mention in the context_clause of any implementation-defined descendants of packages Ada, Interfaces, or System. This restriction applies only to the current compilation or environment, not the entire partition.

From: Robert Dewar
Sent: Monday, July 26, 2010   7:46 PM

Implementations are allowed to add grandchildren to Ada etc. And GNAT
takes advantage of this, e.g. to add the encoding packages to earlier
versions of Ada.

But this creates portability problems, we should really have a
restriction to prevent this, in the style of No_Implementation_Pragmas.

How about No_Implementation_Units

?

I am not really suggesting a new AI at this stage, just some guidance
on whether this is a good idea so that implementations can adopt it
(and then we can put it into Ada 2019 :-))

****************************************************************

From: Tucker Taft
Sent: Monday, July 26, 2010   8:14 PM

This sounds like a very good idea.
Users are often confused about what
packages are "standard" Ada and what
are not.

Does this also cover System.* and Interfaces.*?
One rule might be to disallow any package that starts with "Ada", "System",
or "Interfaces" that is not in the reference manual.  These are the ones
that confuse users.

****************************************************************

From: Robert Dewar
Sent: Monday, July 26, 2010   8:33 PM

Right, that's what I had in mind.

And the idea would be in particular to forbid use of RM packages in an
inappropriately earlier version of Ada (e.g. using the string encoding packages
in Ada 2005 mode). Of course I know that can't be part of the standard, but
that would be the encouraged usage (and is what GNAT intends to do).

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 10, 2011   1:01 AM

A vaguely related suggestion from back in July:

Robert Dewar has suggested:

How about {a restriction} No_Implementation_Units?

Tucker suggested:

One rule might be to disallow any package that starts with "Ada", "System",
or "Interfaces" that is not in the reference manual.  These are the ones that
confuse users.

I was thinking that we could address this in this AI as well (I filed the
mail that way). I realize it would have helped if I had told Bob that at
some point. :-)

Anyway, are there any objections to this idea?? (If there are any, we'll
have to do it as a separate AI.)

****************************************************************

From: Robert Dewar
Sent: Thursday, February 10, 2011   5:23 AM

> One rule might be to disallow any package that starts with "Ada",
> "System", or "Interfaces" that is not in the reference manual.  These
> are the ones that confuse users.

Yes, that's my intention exactly for this restriction

****************************************************************

From: Dan Eilers
Sent: Thursday, February 10, 2011  11:35 AM

> One rule might be to disallow any package that starts with "Ada",
> "System", or "Interfaces" that is not in the reference manual.  These
> are the ones that confuse users.

There is a related issue of disallowing implementation-dependent indentifiers
declared in package System, such as System.Max_Priority.

****************************************************************

From: Tucker Taft
Sent: Thursday, February 10, 2011  11:53 AM

Good point.  These are also sources of non-portability.
In this case, I presume the restriction would be on
*use* of such an identifier, since you probably don't expect there to be a
version of System just sitting around that omits these things.

Perhaps "pragma Restrictions(Pristine);"? ;-)

****************************************************************

From: Bob Duff
Sent: Thursday, February 10, 2011   1:48 PM

> A vaguely related suggestion from back in July:

Very vaguely.  ;-)

> Robert Dewar has suggested:
>
> How about {a restriction} No_Implementation_Units?
>
> Tucker suggested:
>
> One rule might be to disallow any package that starts with "Ada",
> "System", or "Interfaces" that is not in the reference manual.  These
> are the ones that confuse users.
>
> I was thinking that we could address this in this AI as well (I filed
> the mail that way). I realize it would have helped if I had told Bob
> that at some point. :-)

No need to tell me -- I saw those e-mails in AI05-0153-3.

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.  He wrote:

    I am not really suggesting a new AI at this stage, just some guidance
    on whether this is a good idea so that implementations can adopt it
    (and then we can put it into Ada 2019 :-))

> Anyway, are there any objections to this idea?? (If there are any,
> we'll have to do it as a separate AI.)

I'm opposed to putting this feature in the standard at this time.
It just doesn't seem worth the trouble, and it doesn't seem particularly related
to aspects.

But I don't feel strongly about it, and if it goes in, I'd be happy to put it in
this AI.

Dan Eilers wrote:

> There is a related issue of disallowing implementation-dependent
> indentifiers declared in package System, such as System.Max_Priority.

And Tucker Taft replied:

> Good point.  These are also sources of non-portability.
> In this case, I presume the restriction would be on
> *use* of such an identifier, since you probably don't expect there to
> be a version of System just sitting around that omits these things.
>
> Perhaps "pragma Restrictions(Pristine);"? ;-)

This goes way, way too far, in my opinion.  Ada just has way to many potential
non-portabilities.  I mean, any use of Integer is potentially non-portable, and
you can't use String without Integer.  A from-scratch language design could do
much better (see Java), but it's too late for Ada.

Please stop inventing new "nice to have" features!

****************************************************************

From: Robert Dewar
Sent: Thursday, February 10, 2011   6:29 PM

> This goes way, way too far, in my opinion.  Ada just has way to many
> potential non-portabilities.  I mean, any use of Integer is
> potentially non-portable, and you can't use String without Integer.  A
> from-scratch language design could do much better (see Java), but it's too late for Ada.

wrt integer, Ada is as portable as Java, Ada Integer means 32 bits on any
platform supporting Java (care to find a realistic counter example?)

****************************************************************

From: Robert Dewar
Sent: Thursday, February 10, 2011   6:47 PM

I believe Randy's compiler for Windows has 16-bit Integer.
He can correct me if I'm wrong.

And some Ada compilers do Integer arithmetic (intermediate results) in 64 bits.
Java is more portable, in that it requires a particular wrong answer on
"overflow".  ;-)

And if you don't buy the Integer example, try Long_Integer
-- gcc/gnat has both 32-bit and 64-bit versions (which caused me a big headache
when helping to port it to 64-bit Windows!).

Anyway, so what?  My point is I don't want to go tracking down all the potential
non-portabilities, and then have to argue about whether Integer'Last is more or
less portable than Priority'Last.

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 10, 2011   6:53 PM

All Intel-based versions of Janus/Ada have always had Integer as a 16-bit type;
that originally was to keep the binary files created by the various Janus/Ada
compilers intercompatible (this was in the Ada 83 days, before streams). A
related issue was far too much use of "Integer" to mean 16-bits in the runtime
(most of that has been squeezed out in the intervening years).

It would be easy enough to change (essentially, change the definition of
Standard and recompile everything), but even now, a lot of Sequential_IO and
Direct_IO files would be incompatible. I've wanted to make this switchable with
a command line switch, but that turns out to be a lot harder to accomplish.

In any case, it provides a fine test for supposely portable Ada code:
probably 75% of it fails to run on Janus/Ada because it has assumed a range for
Integer. Using a properly declared type fixes that.

****************************************************************

From: Robert Dewar
Sent: Thursday, February 10, 2011   6:58 PM

> All Intel-based versions of Janus/Ada have always had Integer as a
> 16-bit type; that originally was to keep the binary files created by
> the various Janus/Ada compilers intercompatible (this was in the Ada
> 83 days, before streams). A related issue was far too much use of
> "Integer" to mean 16-bits in the runtime (most of that has been
> squeezed out in the intervening years).

Right, but these days that is just not viable in an Ada compiler, so I regard
this as an oddity from the past. Limiting strings to 32K bytes is simply not a
viable choice on any modern architecture. So in practice Integer will always be
32 bits on any reasonable modern architecture.

****************************************************************

From: Dan Eilers
Sent: Thursday, February 10, 2011   7:05 PM

> Anyway, so what?  My point is I don't want to go tracking down all the
> potential non-portabilities, and then have to argue about whether
> Integer'Last is more or less portable than Priority'Last.

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.

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.

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.

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 10, 2011   7:10 PM

...
> No need to tell me -- I saw those e-mails in AI05-0153-3.
>
> 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. ;-)

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.

> > Anyway, are there any objections to this idea?? (If there are any,
> > we'll have to do it as a separate AI.)
>
> I'm opposed to putting this feature in the standard at this time.
> It just doesn't seem worth the trouble, and it doesn't seem
> particularly related to aspects.
>
> But I don't feel strongly about it, and if it goes in, I'd be happy to
> put it in this AI.

OK, but I don't see how we can decide here whether it is in or out; so I think
I'll just make a separate AI and you can vote against it if you like.

> Dan Eilers wrote:
>
> > There is a related issue of disallowing implementation-dependent
> > indentifiers declared in package System, such as System.Max_Priority.
>
> And Tucker Taft replied:
>
> > Good point.  These are also sources of non-portability.
> > In this case, I presume the restriction would be on
> > *use* of such an identifier, since you probably don't expect there
> > to be a version of System just sitting around that omits these things.
> >
> > Perhaps "pragma Restrictions(Pristine);"? ;-)
>
> This goes way, way too far, in my opinion.  Ada just has way to many
> potential non-portabilities.  I mean, any use of Integer is
> potentially non-portable, and you can't use String without Integer.  A
> from-scratch language design could do much better (see Java), but it's
> too late for Ada.

I agree with Bob in this case. When you use anything from package System (or
package Standard or package Interfaces for that matter), you are taking a level
of non-portability. If you want to avoid that non-portability, use pragma
No_Dependence. No new features are needed for that.

> Please stop inventing new "nice to have" features!

I don't even believe that this is a "nice to have" feature. System's contents
are inherently non-portable. Using it in the first place means that you want to
do something at a low level. Expecting more than that makes no sense.

To take a particular example, type Address in the 16-bit x86 versions of
Janus/Ada is a record type with Segment and Offset components. Since Ada 83
doesn't have any Address constructor at all, the only way to set an Address
value is to initialize it with an aggregate. (If we had done an Ada 95 compiler
for that system, we would have done some sort of mapping from Integer_Address,
but that would be even less portable).

Indeed, most of our 32-bit x86 versions of Janus/Ada used a 48-bit version of
Address (again with segment and offset parts), since that matches the actual
hardware capabilities. (A lot of malware could have been avoiding if Windows had
put the code and data into different segments!!) We eventually had to get of
that on Windows because of problems with the segment registers getting clobbered
by foreign code.

Anyway, my point is that System is inherently system-dependent. It wouldn't be
usable without some level of that; I don't see any value to picking out
particular things in that package and saying they should be called out by a
restriction.

****************************************************************

From: Dan Eilers
Sent: Thursday, February 10, 2011   7:58 PM

> I don't even believe that this is a "nice to have" feature. System's
> contents are inherently non-portable. Using it in the first place
> means that you want to do something at a low level. Expecting more
> than that makes no sense.

Actually, people intending write fully portable Ada code end up unwittingly
using System.Max_Priority.  See the ChameneosRedux benchmark program at:

http://shootout.alioth.debian.org/u32/program.php?test=chameneosredux&lang=gnat

It says:

   -- Fully portable :
   --            No machine/OS dependency
   --            No dependency of GNAT-compiler specific features


and then does:

   procedure ChameneosRedux is
      pragma Priority (System.Max_Priority);

****************************************************************

From: Tucker Taft
Sent: Thursday, February 10, 2011   8:13 PM

I suspect that if you suggest a reasonable name for the restriction, GNAT folks
might add support for it.  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.

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 10, 2011   8:40 PM

> and then does:
>
>    procedure ChameneosRedux is
>       pragma Priority (System.Max_Priority);

Sure, but so what? 90% of the supposedly "portable" code that I've seen has some
compiler dependency. The only code that doesn't have been compiled and debugged
on multiple compilers, and there is very little than that. Most such code
depends on GNAT features, of course, but it works just as well in the reverse:
most of my "portable" code has proven to have some Janus/Ada dependency when
compiled with GNAT or ObjectAda.

I cannot imagine any way to even come close to banning all of these
incompatibilities via a restriction. The biggest problem porting to/from
Janus/Ada is the 16-bittedness of type Integer, but there is no restriction to
handle that. And if you had one to fix that, there would be plenty of other
issues. Including ones of source representation (which no restriction could ever
have an impact on).

In any case, the use of System is inherently non-portable. The program cited
above immediately left the realm of portable code simply by using System.
(Dependence on priorities is non-portable for instance; there is no reason to
assume a compiler supports more than one, and in that case you do not need any
Priority pragmas.)

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 10, 2011   8:51 PM

...
> 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.

Dependence on the things defined by the standard is just as likely to cause
non-portabilities. (The obvious example being the number of bits in Integer, but
it applies to virtually everything in System.) The form of specifying an address
(as a number, or a record, or whatever) is clearly not portable (unless the
compiler follows the implementation advice and supports none, but even then, the
interpretation of Integer_Address is implementation-defined). Unless the
restriction plugged most of these things, it is just providing false hope.

The only Ada code that can be considered portable is that compiled and tested on
more than one Ada compiler. It is quite unlikely that such things would survive
such a gauntlet (and even then, they do). [Keep in mind that we made Claw run on
5 different compilers; it takes quite a concerted effort, even when the code was
constructed to be portable from the beginning.]

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.

****************************************************************

From: Tucker Taft
Sent: Thursday, February 10, 2011   9:42 PM

I think you are taking a narrow view of this.
Apparently your experience is different from mine in this area.

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.

That is really the purpose of these restrictions:
to catch unintentional uses of non-standard features, be they attributes,
pragmas, units, elements of package Standard, etc.  It doesn't suddenly make
your program portable, but it does help to reduce the number of *unnecessary*
non-portabilities.

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 10, 2011  10:06 PM

But this is an endless slippery slope of restrictions. First the obvious ones,
then you add restrictions for non-standard additions to System, then about
non-standard additions to other packages (there are several that allow that),
then any dependence on the contents of the Implementation packages of the Queue
containers, then on non-required types in Standard (Long_Integer, etc.), then on
Standard.Integer itself, then ...

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.

And then the question is whether people really are going to use all of these
restrictions. That seems doubtful as well.

We could, I suppose, wrap all of these restrictions into a profile, but that
doesn't really help the implementation cost of having to deal with so many
restrictions. (I'm unconvinced that restrictions are the best way to handle this
in any case.)

So I don't buy it. I'm drawing the line at No_Implementation_Units, and I won't
complain if it goes nowhere as well.

****************************************************************

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!! :-) :-)

****************************************************************