!standard 13.12.1(3/2) 11-02-11 AI05-0242-1/01 !class Amendment 11-02-11 !status work item 11-02-11 !status received 11-02-09 !priority Low !difficulty Easy !subject No_Implementation_Units restriction !summary A new restriction is defined: pragma Restrictions(No_Implementation_Units); !problem Implementations are allowed to add implementation-defined units as descendants of the standard packages, and users can do so as well. For instance, it is not uncommon for implementations to provide additional containers packages as children of Ada.Containers. It can be confusing as to whether these units are language-defined. This is important when creating portable code, as implementation-defined units are unlikely to be available on other implementations. !proposal (See wording.) !wording Add after 13.12.1(3/2): 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. !discussion (See proposal.) !example pragma Restrictions(No_Implementation_Units); !ACATS test Add a ACATS B test for this feature. !ASIS No ASIS effect (Restrictions are not handled specially by ASIS). !appendix 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 <>. 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!! :-) :-) ****************************************************************