CVS difference for ai05s/ai05-0183-1.txt
--- ai05s/ai05-0183-1.txt 2012/02/19 04:54:04 1.30
+++ ai05s/ai05-0183-1.txt 2012/04/20 01:24:18 1.31
@@ -3880,6 +3880,21 @@
****************************************************************
+From: Robert Dewar
+Sent: Monday, October 25, 2010 3:08 PM
+
+Did we (by default if no other way) decide that all aspects get delayed to the
+end of the declarative region, i.e. that this works fine:
+
+ type R is range 1 .. 10 with
+ Size => R_Size;
+ R_Size : constant := 8;
+
+I don't really mind, but I would like to implement what's decided. I am still
+a bit worried about circular address clauses.
+
+****************************************************************
+
From: Tucker Taft
Sent: Monday, October 25, 2010 2:55 PM
@@ -4003,6 +4018,150 @@
****************************************************************
+From: Robert Dewar
+Sent: Thursday, October 28, 2010 5:29 AM
+
+Back to implementation .. I am still furiously trying to figure out a way to do
+even a partial job of the proposed requirements for aspects of making it illegal
+for the visibiliy to change between the freeze point and the end of the
+declarative part.
+
+This is *really* hard, because analysis in our compiler has all kinds of side
+effects (generating error messages if the analysis fails, generating
+cross-references, generating internal entities, etc) all of which is really hard
+to turn off for a trial visibility analysis).
+
+I think the best I can do for now is the warning I proposed:
+
+ warning: "foo" aspects analyzed here (at freezing point)
+
+or some such, the warning can easily be suppressed in the common case where
+there is obviously no possibility of a shift in visibility (e.g. Size => 32),.
+
+Oddly PAck => True (if this form survives) is not such a case because of the
+infamous possibility of
+
+ True : Booelan := False;
+
+on the other hand, this is just a warning, so we really don't need the warning
+if someone writes an idiotic test that does this :-)
+
+In practice I suspect the ONLY case where there is a concern will be the (rather
+worrisome) example of the call to an overridden function.
+
+Will be interesting to see how many false positives such a warning generates.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, October 28, 2010 7:14 AM
+
+Could you create two copies of the tree, analyze one at the freezing point, and
+the other at the end of the enclosing declaration list, and then do your normal
+expression conformance check between them, similar to what you do between the
+default expressions on a spec and a body?
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, October 28, 2010 7:24 AM
+
+The problem is that this bogus analysis will have all sorts of side effects,
+such as making bogus extra references, and creating bogus internal entities not
+to mention generating bogus error messages if the second analysis simply fails
+because the new visibility gives e.g. type errors. Of course such type errors
+would be formally conforming, but could result in very obscure messages.
+
+Looking at this right now, using the conformance mechanism is indeed an
+interesting idea.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, October 28, 2010 7:30 AM
+
+> This is *really* hard,...
+
+Yeah, I really doubt it's worth all this trouble.
+Can't we solve the problem with some warnings?
+E.g. collect up a set of names used in the aspect expression, and see if
+something of the same name is later declared. Or something like that.
+
+Tucker's rule is far more elegant, but nobody planned for that in their compiler
+designs.
+
+> In practice I suspect the ONLY case where there is a concern will be
+> the (rather worrisome) example of the call to an overridden function.
+
+Well, we could record a use of a primitive in an aspect, and wanrn later if it
+gets overridden. Or something like that.
+
+P.S. Sorry you're sick. Take it easy, and get well soon!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, October 28, 2010 7:36 AM
+
+> Tucker's rule is far more elegant, but nobody planned for that in
+> their compiler designs.
+
+I am seeing if I can kludge something that is general, stay tuned!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, October 29, 2010 11:56 AM
+
+OK, installed a rather giant kludge, but it's at least beginning to work:
+
+(I do find that example that Tuck quoted convincing!)
+
+ 1. pragma Ada_2012;
+ 2. package AspectVis is
+ 3. R_Size : constant Integer := 32;
+ 4.
+ 5. package Inner is
+ 6. type R is new Integer with
+ 7. Size => R_Size;
+ |
+ >>> visibility of aspect for "R" changes after freeze point
+
+ 8. F : R; -- freezes
+ |
+ >>> info: "R" is frozen here, aspects evaluated at this point
+
+ 9. R_Size : constant Integer := 64;
+ 10. S : constant Integer := R'Size; -- 32 not 64
+ 11. end Inner;
+ 12. end AspectVis;
+
+ 12 lines: 1 error, 1 warning
+Tuck, thanks for the suggestion of using conformance checking to compare the two
+expressions, very valuable!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, October 29, 2010 2:33 PM
+
+Ha, I found an interesting bug in using conformance to check equivalence of
+expressions
+
+ A : Integer := 32;
+ package P is
+ type R is new integer with Size => A;
+ RR : R;
+ A : Integer := 32;
+ end P;
+
+the expression ends up being a static expression with value 32 before and after
+the freeze, so they conform, but do not meet the rule of names being separate.
+
+Fixable, but entertaining!
+
+****************************************************************
+
From: Brad Moore
Sent: Friday, November 12, 2010 8:24 AM
@@ -6957,5 +7116,44 @@
If you have a proposal for dealing with this that does not require "alternative"
rules, please make it, but in the absence of some sort of concrete proposal I
don't think that I can do anything with this comment.
+
+****************************************************************
implementing semantic features.
+
+From: Robert Dewar
+Sent: Saturday, September 20, 2011 at 12:28 PM
+
+impl defined syntax for aspects
+is quite fun, here is a fun aspect for a function
+
+ with C_Implementation =>
+ int a (int b)
+ {return (b + b);};
+
+My understanding is that this is conforming :-)
+
+****************************************************************
implementing semantic features.
+
+From: Randy Brukardt
+Sent: Saturday, September 20, 2011 at 12:28 PM
+
+I would agree.
+
+It's impossible to decide what would be going too far, so we pretty much have to
+allow anything.
+
+While the above might be dubious, if the language in question was not much like
+Ada (such as a formal specification language or perhaps a theorem proving
+language like Prolog), it might even make sense by bringing to Ada capabilities
+that would be hard otherwise. Indeed, this might provide a way to get SQL really
+into Ada.
+
+Aside: Janus/Ada includes a bunch of pragmas for creating Windows resource
+objects within the Ada program -- that's valuable as it provides the best way to
+get Ada symbols into the resource data. One could imagine having modeled those
+as aspects instead, attaching them to the associated objects.
+
+Anyway, my point from all of these ramblings is simply that this capability will
+open up all kinds of possibilities for the clever compiler-writer, and could
+allow Ada mechanisms to support things that would otherwise be inconceivable.
****************************************************************
implementing semantic features.
Questions? Ask the ACAA Technical Agent