CVS difference for ais/ai-00366.txt

--- ais/ai-00366.txt	2004/02/06 05:01:49	1.3
+++ ais/ai-00366.txt	2004/02/21 04:15:11	1.4
@@ -550,6 +550,71 @@
 
 ****************************************************************
 
+From: Robert I. Eachus
+Sent: Friday, February 6, 2004  5:39 PM
+
+Robert Dewar wrote:
+
+> Why burden it with all this junk. It is fine to use 'Image for numeric
+> stuff, have Simple_IO just do string stuff (have a look at GNAT.IO), or
+> better I will give the spec here. This has proved very useful:
+
+I argee with Robert Dewar.  That's what the "No. Feature Creep." in the
+message was saying.  But the edited message as RBKD answered it is not
+how it looked to me.  (It may just have been where the line breaks fell...)
+
+To be clear, I thought I was seconding Robert Dewar's suggestion, and
+noting that any support for other types in Standard could be pushed to
+child packages if a vendor wanted to include such support.
+
+I was also serious that in Ada 0Y we should at least require
+Long_Integer and Long_Float.  Implementors who actually have only one
+base integer or floating point type could just put in a renames. There
+is little or no hardship for implementors there.  But I am writing more
+and more code that uses Long_Float by default.  I've never had to modify
+any of it to compile on a system that didn't support Long_Float, even
+though such a modification is also trivial.  If everyone is supporting
+Long_Float, why don't we say so?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 6, 2004  5:40 PM
+
+Robert Dewar said:
+
+> Why burden it with all this junk. It is fine to use 'Image for numeric
+> stuff, have Simple_IO just do string stuff (have a look at GNAT.IO), or
+> better I will give the spec here. This has proved very useful:
+
+I totally agree about the string-only stuff. I've been making do with a
+single logger procedure, after all.
+
+But the spec. you provided don't allow output to files. That won't do.
+Virtually all of the programs I work on these days either run unattended
+(web server, spam filter) or are GUI programs. In neither case, can you use
+Standard_Output (the unattended programs because there is no screen, and the
+logging is a permanent function used for debugging of production errors; the
+GUI programs because having a standard output window on the screen can
+interfere with the behavior that you are trying to debug -- or it is
+unreadable, because it is underneath the program's windows).
+
+So I think the package needs Open, Create, Close, and Delete. (But not
+necessarily Name or Form or Reset, as those tend to make the implementation
+harder). And I'd leave out Set_Output; it complicates things when you have
+files and you certainly can work around not having it.
+
+But the other operations are just about right.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, February 6, 2004  5:44 PM
+
+I agree that Long_Float should be unconditionally supported.
+
+****************************************************************
+
 From: Robert A. Duff
 Sent: Thursday, February 5, 2004  8:24 AM
 
@@ -746,3 +811,342 @@
 
 ****************************************************************
 
+From: Robert Dewar
+Sent: Friday, February 6, 2004  4:12 PM
+
+Randy Brukardt wrote:
+> Our compiler design is all-Ada top to bottom. The linker is of our own
+> design, and creates a executable directly (no other programs run). This is
+> the standard mode. That's not negotiable; we control the entire toolchain,
+> and that's a requirement if you're staking your business on it.
+
+An exceedingly odd claim. Any real Ada compiler must depend on
+proprietary tool chains to be any use at all in my view. Anyway
+for sure this is off topic. I must say I agree with Bob Duff's view
+here that pragma Import Ada must work as he expects.
+
+> Now, the problem is you (Bob) are suggesting two uses for pragma Import:
+>
+>     * To link to code somewhere else within the Ada program; and
+>     * To link to code external to the Ada program.
+>
+> The fact that the convention is "Ada" doesn't really change this; you still
+> want to be to link to other, separate Ada (or assembler!) subsystems using
+> the system linker.
+
+Yes, both are reasonable, both should work
+
+> The problem is that there is no way to tell those apart; but they are using
+> *different* linkers. The "solution" is simply to assume that you are linking
+> to code external to the program (that works on internal code by accident);
+> but that implies that you are using the "secondary" toolchain. And it also
+> implies very substandard code (all imports call through thunks so that the
+> actual external reference occurs in only one place).
+
+That's an artifact of your peculiar linking approach. The Ada design
+clearly anticipates a conventional approach to linking.
+
+> Even if, by some miracle, you could figure out which was which, it still
+> would be impossible, because the Ada linker does not use link names. It
+> simply uses address offsets, which of course change every time a change (or
+> even recompile with different switches) occurs to a spec. You can't put them
+> into "pragma Import" code because the only way to find out the right address
+> is to with the appropriate package -- which defeats the purpose of the
+> Import.
+
+Well as I say, I think you have chosen a model that makes it very
+hard for you to do Import/Export correctly.
+
+> The beauty of Ada is that you *don't* have to depend on unreliable
+> code/tools from a whole bunch of unreliable vendors (just one unreliable Ada
+> vendor!) - you can do it *all* in Ada. Now, it obvious that sometimes you
+> need to access C, but (on Windows, at least) it's a lot rarer than people
+> make out. (I believe that you can run any Claw GUI program and almost any
+> Win32 program without any use of imported C code in the executable. Of
+> course, you're using the C code that makes up the Windows kernel - AdaOS
+> doesn't exist yet - but you need no Microsoft tools or code to create
+> running programs.)
+
+I don't buy this claim. I think your implementation (linking) approach
+is fundamentally flawed, and the difficulties you are having with
+Import/Export (Ada) are just a symptom of this.
+
+> We of course validated all of our compilers in the standard linker; we used
+> the alternate chain only on C interface programs. (With the exception of
+> Windows, for which the standard linker didn't exist when we validated.) I
+> would be *very* upset if that did not remain true.
+
+I don't see any basis for upset. I suspect that virtually all Ada 95
+compilers do Import/Export Ada the way Bob expects it to work, and in
+fact it is a handy way of avoiding certain elaboration problems (very
+low level and junky, but sometimes you need that).
+
+Quite a few of the DEC tests use this capability, so ACT was actually
+contractually obligated to get this working (of course it worked out
+of the box, if you use a standard linking approach, it will).
+
+I think the approach Randy describes is suitable for Ada 83, but not
+for Ada 95. That is, I agree with him that it seems very hard to make
+this approach work properly.
+
+Perhaps we should indeed discuss this in the ARG, and decide what is
+and what is not supposed to work in this regard.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 6, 2004  5:28 PM
+
+Robert Dewar wrote:
+
+> Randy Brukardt wrote:
+> > Our compiler design is all-Ada top to bottom. The linker is of our own
+> > design, and creates a executable directly (no other programs run). This is
+> > the standard mode. That's not negotiable; we control the entire toolchain,
+> > and that's a requirement if you're staking your business on it.
+>
+> An exceedingly odd claim. Any real Ada compiler must depend on
+> proprietary tool chains to be any use at all in my view.
+
+Why? It wasn't necessary for CP/M and MS-DOS, it isn't necessary for Windows
+(you can access all of Win32 and any DLL without using any Microsoft or
+other tool), and it certainly isn't necessary for bare machines. The only
+place that I'm familiar with that it *is* necessary is on Unix/Linux
+systems - and I consider that a design fault in those systems. (It is
+actually possible to build a full Ada compiler on Intel ABI machines without
+using any stuff from any Unix - our SCO compiler did exactly that - but I
+wouldn't do it again because too much stuff is implemented in the C
+libraries rathe in the Kernel.)
+
+Indeed, I don't see any Microsoft tools used in the Windows version of GNAT.
+You can use it out of the box to make programs for Windows without getting
+anything else. So what proprietary tools do you need?
+
+...
+> > The beauty of Ada is that you *don't* have to depend on unreliable
+> > code/tools from a whole bunch of unreliable vendors (just one unreliable Ada
+> > vendor!) - you can do it *all* in Ada. Now, it obvious that sometimes you
+> > need to access C, but (on Windows, at least) it's a lot rarer than people
+> > make out. (I believe that you can run any Claw GUI program and almost any
+> > Win32 program without any use of imported C code in the executable. Of
+> > course, you're using the C code that makes up the Windows kernel - AdaOS
+> > doesn't exist yet - but you need no Microsoft tools or code to create
+> > running programs.)
+>
+> I don't buy this claim. I think your implementation (linking) approach
+> is fundamentally flawed, and the difficulties you are having with
+> Import/Export (Ada) are just a symptom of this.
+
+Fine. I want an all-Ada world as much as possible. I realize the current
+state of the world makes that impractical most of the time. But I don't
+believe for a minute that the standard insists on anything that would make
+it impossible to have an all-Ada world. If we cannot at least strive for a
+more perfect world
+
+> > We of course validated all of our compilers in the standard linker; we used
+> > the alternate chain only on C interface programs. (With the exception of
+> > Windows, for which the standard linker didn't exist when we validated.) I
+> > would be *very* upset if that did not remain true.
+>
+> I don't see any basis for upset. I suspect that virtually all Ada 95
+> compilers do Import/Export Ada the way Bob expects it to work, and in
+> fact it is a handy way of avoiding certain elaboration problems (very
+> low level and junky, but sometimes you need that).
+
+It is exceedingly bad practice to have dependencies within an Ada program
+not documented in the context clause. I see absolutely no reason to
+encourage that - even if, as a practical matter, you'll need to once in a
+great while do something exceedingly bad. (In which case, you can use the
+alternative toolchain set up for that purpose. Just don't ask us to validate
+it - once you're depending on unknown external code, there is essentially
+nothing we can do to insure correctness.) Any rep. clause pointing inside of
+the Ada code itself is a terrible idea. [I know people do this as a
+workaround for "in out" function parameters, for example, but I find that
+horrific -- fix the root problem (using the wrong mode on the parameter),
+don't stand on your head. And lobby to get the language fixed...]
+
+> I think the approach Randy describes is suitable for Ada 83, but not
+> for Ada 95. That is, I agree with him that it seems very hard to make
+> this approach work properly.
+
+In general, approaches that worked for Ada 83 were supposed to continue
+working in Ada 95. We explicitly pointed out where we expected that *not* to
+be true. I would consider anything in the standard that make requirements to
+the contrary to fall under the Dewar rule "the standard never says anything
+silly".
+
+...
+> Perhaps we should indeed discuss this in the ARG, and decide what is
+> and what is not supposed to work in this regard.
+
+I think that this would be a particularly bad use of the ARG's time. I can't
+imagine anything good that would come out of such a discussion - any
+conclusion is going to be considered very bad by someone, and I certainly
+don't hear users complaining about this issue.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, February 6, 2004  6:38 PM
+
+Randy Brukardt wrote:
+
+>>An exceedingly odd claim. Any real Ada compiler must depend on
+>>proprietary tool chains to be any use at all in my view.
+>
+> Why? It wasn't necessary for CP/M and MS-DOS,
+
+Most people would not consider those operating systems, and you
+were talking about Ada 83, not Ada 95.
+
+  it isn't necessary for Windows
+
+You are arguing in a circular manner. You argue that the language
+allows your approach, which then validates the approach, which you
+then use to invalidate an important feature of the language (export
+import Ada).
+
+>>Perhaps we should indeed discuss this in the ARG, and decide what is
+>>and what is not supposed to work in this regard.
+
+> I think that this would be a particularly bad use of the ARG's time. I can't
+> imagine anything good that would come out of such a discussion - any
+> conclusion is going to be considered very bad by someone, and I certainly
+> don't hear users complaining about this issue.
+
+You might be right, I think the major complete language Ada 95 compilers
+do in fact fully implement pragma import/export for Ada anyway.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 6, 2004  6:57 PM
+
+Robert Dewar:
+>   it isn't necessary for Windows
+>
+> You are arguing in a circular manner. You argue that the language
+> allows your approach, which then validates the approach, which you
+> then use to invalidate an important feature of the language (export
+> import Ada).
+
+Well, clearly the problem is the "important feature of the language".
+
+I view Import/Export Ada to be something of no particular value that
+naturally fell out of the other definitions (sort of like non-binary modular
+types). It's for external interfacing to other Ada subsystems: a very rare
+event. Some people have found a way to abuse this capability in order to
+end-run Ada's protections.
+
+> >>Perhaps we should indeed discuss this in the ARG, and decide what is
+> >>and what is not supposed to work in this regard.
+>
+> > I think that this would be a particularly bad use of the ARG's time. I
+can't
+> > imagine anything good that would come out of such a discussion - any
+> > conclusion is going to be considered very bad by someone, and I
+certainly
+> > don't hear users complaining about this issue.
+>
+> You might be right, I think the major complete language Ada 95 compilers
+> do in fact fully implement pragma import/export for Ada anyway.
+
+Certainly Janus/Ada does: but only if you use the alternative toolchain. And
+we don't provide or support the external parts (i.e. the ones from
+Microsoft) needed for that. And that's not a problem for customers: if
+you're going to link C code, you need a C compiler anyway. But I don't want
+to have to make Ada-only customers have to purchase full-blown development
+systems from elsewhere, and I don't want our validations depending on tools
+that we don't provide or support.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, February 6, 2004  7:17 PM
+
+Randy Brukardt wrote:
+
+> Some people have found a way to abuse this capability in order to
+> end-run Ada's protections.
+
+Sounds like you are saying you don't like the feature. OK, everyone
+has that privilege, but it is part of the language, and its ability
+to bypass in a very deliberate way protections that are in the language
+is useful, just as address overlays are useful. In any case, the
+feature is there, it must be implemented whether you like it or not :-)
+
+> Certainly Janus/Ada does: but only if you use the alternative toolchain. And
+> we don't provide or support the external parts (i.e. the ones from
+> Microsoft) needed for that.
+
+OK that's fine.
+
+> And that's not a problem for customers: if
+> you're going to link C code, you need a C compiler anyway. But I don't want
+> to have to make Ada-only customers have to purchase full-blown development
+> systems from elsewhere, and I don't want our validations depending on tools
+> that we don't provide or support.
+
+Well to validate import/export, you need external compilers anyway,
+so I don't know what you are talking about here. The ACATS tests
+have non-Ada in them.
+
+It seems perfectly fine to tell your users that to use pragma
+Import/Export Ada they need the alternative toolchain.
+
+I do think the ACATS tests should test Import/Export Ada, since
+this is definitely a feature that is used, and I consider it an
+important feature.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 6, 2004  7:55 PM
+
+Robert Dewar:
+
+> Sounds like you are saying you don't like the feature. OK, everyone
+> has that privilege, but it is part of the language, and its ability
+> to bypass in a very deliberate way protections that are in the language
+> is useful, just as address overlays are useful.
+
+Another mis-feature that ought to be restricted as much as possible. As with
+Imports, the danger  is creating an overlay by accident. I'd prefer users
+that have to put "pragma Warranty_Void();" on any address overlays before
+they'd work. :-)
+
+...
+> Well to validate import/export, you need external compilers anyway,
+> so I don't know what you are talking about here. The ACATS tests
+> have non-Ada in them.
+
+We used "special options" (which actually was a completely different set of
+programs) for the Interface C tests. The reason was the need to link foreign
+language code. That reason would not apply to Import/Export Ada.
+
+> It seems perfectly fine to tell your users that to use pragma
+> Import/Export Ada they need the alternative toolchain.
+>
+> I do think the ACATS tests should test Import/Export Ada, since
+> this is definitely a feature that is used, and I consider it an
+> important feature.
+
+Well, given the budget of the ACAA, and the feeling of vendors, I doubt that
+there is going to be many (if any) new ACATS tests on Ada other than those
+steming from the Corrigendum and (soon) the Amendment. There are lots of
+core rules (supposedly 30%, although I think the actual number of testable
+ones is more like 10%) that matter to users (read-only access to protected
+components from functions, for one example) that are untested - it's hard to
+imagine how to choose what ought to be tested. Vendors don't want hundreds
+of new tests.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, February 6, 2004  3:40 PM
+
+Making Text_IO preelaborated is far too big a change, it might result in
+a need for a radical reimplementation. There is simply nothing to justify
+such a huge change.
+
+****************************************************************