CVS difference for ai12s/ai12-0138-1.txt

Differences between 1.5 and version 1.6
Log of other versions for file ai12s/ai12-0138-1.txt

--- ai12s/ai12-0138-1.txt	2015/02/24 23:49:48	1.5
+++ ai12s/ai12-0138-1.txt	2015/02/26 00:09:52	1.6
@@ -1,9 +1,10 @@
-!standard 13.1.1(34/3)                                  15-02-24  AI05-0138-1/04
+!standard 13.1.1(34/3)                                  15-02-25  AI05-0138-1/05
 !standard 4.1.5(5/3)
+!standard 4.1.6(5/3)
 !standard 4.1.6(6/3)
 !standard 4.1.6(7/3)
 !standard 4.1.6(8/3)
-!standard 5.5.1(21/3)
+!standard 5.5.1(11/3)
 !class binding interpretation 14-10-13
 !status work item 14-10-13
 !status received 14-06-26
@@ -13,9 +14,9 @@
 !subject Iterators of formal derived types
 !summary
 
-We define the notion of an "immutable" aspect, and declare Default_Iterator,
+We define the notion of an "unalterable" aspect, and declare Default_Iterator,
 Iterator_Element, Implicit_Dereference, Constant_Indexing, and
-Variable_Indexing to be immutable aspects. These aspects don't allow
+Variable_Indexing to be unalterable aspects. These aspects don't allow
 redefinition for derived types.
 
 !question
@@ -38,37 +39,37 @@
 
 !wording
 
-Insert after 13.1.1(34/3).
+Insert after 13.1.1(34/3) (and perhaps add "Legality Rules" in front of 34/3):
 
-  Certain type-related aspects are defined to be *immutable*.
+  Certain type-related aspects are defined to be *unalterable*.
 
-  If an immutable aspect is directly specified for a type T, then any
+  If an unalterable aspect is directly specified for a type T, then any
   explicit specification of that aspect for any other descendant of T
-  shall denote the same entities as the inherited aspect.
+  shall denote the same entities as would the inherited aspect.
 
-  An immutable aspect shall not be directly specified on a
+  An unalterable aspect shall not be directly specified on a
   full_type_declaration if the type has a partial view that would allow
-  the specification of the same aspect. A derived_type_declaration that
-  has a partial view shall not be a descendant of a type with a
-  specified immutable aspect, unless a matching aspect is also specified
-  for the partial view.
+  the specification of the same aspect. If a type with a partial view
+  inherits an unalterable aspect, then a matching definition shall be
+  specified (directly or by inheritance) for this unalterable aspect of
+  the partial view.
 
   In addition to the places where Legality Rules normally apply (see
-  12.3), this rule applies also in the private part of an instance of a
-  generic unit.
+  12.3), these rules about unalterable aspects apply also in the private
+  part of an instance of a generic unit.
 
   Redundant: [The Default_Iterator, Iterator_Element, Implicit_Dereference,
-  Constant_Indexing, and Variable_Indexing aspects are immutable.]
+  Constant_Indexing, and Variable_Indexing aspects are unalterable.]
 
 ----
 
-Add to the (currently nonexistent) Legality Rules section of 4.1.5 (after 4.1.5(5/3)):
+Add to the Static Semantics section of 4.1.5 (before 4.1.5(6/3)):
 
-    The Implicit_Dereference aspect is immutable (see 13.1.1).
+    The Implicit_Dereference aspect is unalterable (see 13.1.1).
 
 ----
 
-Replace 4.1.6(6-8/3)
+Delete 4.1.6(6-8/3):
 
      The Constant_Indexing or Variable_Indexing aspect shall not be
      specified:
@@ -77,23 +78,15 @@
        - on a full_type_declaration if the type has a tagged partial
          view.
 
-with
+Add after 4.1.6(5/3):
 
-    The Constant_Indexing and Variable_Indexing aspects are immutable (see 13.1.1).
+    The Constant_Indexing and Variable_Indexing aspects are unalterable (see 13.1.1).
 
-
-[Editor's note: This subclause already has the generic boilerplate, so
-we don't need to add it here.]
-
 ----
-
-Add at the end of the Legality Rules section of 5.5.1 (after 5.5.1(21/3):
 
-    The Default_Iterator and Iterator_Element aspects are immutable (see 13.1.1).
+Add at the end of the Static Semantics section of 5.5.1 (after 5.5.1(11/3):
 
-    In addition to the places where Legality Rules normally apply (see
-    12.3), these rules apply also in the private part of an instance of a
-    generic unit.
+    The Default_Iterator and Iterator_Element aspects are unalterable (see 13.1.1).
 
 !discussion
 
@@ -107,11 +100,11 @@
 is fine as it stands. [Editor's note: AI12-0104-1 removed the above wording
 and replaced it by a User Note, which is OK.]
 
-The new Legality rules in 4.1.5, 4.1.6, and 5.5.1 are needed so that privacy
-is not compromised by these rules.
+The rules about partial views in the definition of unalterable aspects are
+needed so that privacy is not compromised.
 
-The first new rule (which was already present in 4.1.6) is needed to prevent
-problems like this one:
+The first new rule on partial views (which was originally in 4.1.6) is
+needed to prevent problems like this one:
 
    package Pkg1 is
       type Rec is record Int : Integer; end record;
@@ -143,7 +136,7 @@
       package I is new G (T2); -- Trouble here if T1 was legal.
    end;
 
-The second new rule is needed to prevent hidden inheritance.
+The second new partial-view rule is needed to prevent hidden inheritance.
 
    package Pkg3 is
       type Parent is tagged null record;
@@ -242,7 +235,7 @@
 From: Randy Brukardt
 Sent: Tuesday, February 24, 2015  5:24 PM
 
-> Here is my take on consolidating the rules relating to "immutable" 
+> Here is my take on consolidating the rules relating to "immutable"
 > aspects.
 
 A quick glance at this suggests that you didn't update the discussion, which
@@ -250,13 +243,13 @@
 then talks about the "first" and "second" new rule. (With your wording, there
 is only one rule in each subclause.) I suspect that the discussion is really
 now about the rules in the new blanket definition.
- 
-> [ASIDE: I will say I am not thrilled with the use of the term 
-> "immutable."  Perhaps "inalterable"?  "Immutable" to me implies it 
-> doesn't change, even by itself, when in fact it can potentially change 
+
+> [ASIDE: I will say I am not thrilled with the use of the term
+> "immutable."  Perhaps "inalterable"?  "Immutable" to me implies it
+> doesn't change, even by itself, when in fact it can potentially change
 > interpretation if we override the denoted subprogram(s).
-> "Inalterable" to me means that we can't change it, but it might still 
-> change interpretation on its own.  Also, "immutable" already is 
+> "Inalterable" to me means that we can't change it, but it might still
+> change interpretation on its own.  Also, "immutable" already is
 > associated with "immutably limited,"
 > which feels to me like a different sense of the word.]
 
@@ -280,5 +273,483 @@
 because you included it in the definition of "immutable aspect". But you left
 it in the new text for 5.5.1. I would have expected 4.1.5 and 5.5.1 to be
 treated the same.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, February 24, 2015  5:58 PM
+
+Humm. You have (I suspect that Steve had originally) placed the definition of
+"immutable aspect" into 13.1.1(34), followed by a bunch of Legality Rules,
+including the boilerplate. But this is a "Static Semantics" section; there
+aren't any "Legality Rules" here; so the boilerplate does have any effect. Not
+what we want. This text should go in the Legality Rules section.
+
+And the generic boilerplate here probably needs to make clear that the Legality
+Rules its talking about are those for "immutable aspects" and not (necessarily)
+all of the other rules in this clause. (That's always a problem when one uses
+"these rules", but here it seems acute. Of course, the question arises whether
+in fact the rest of these rules need the boilerplate as well, since about 98%
+of the time that's true, but I don't want to make my head hurt. :-) So how
+about:
+
+  In addition to the places where Legality Rules normally apply (see
+  12.3), these rules {for immutable aspects} apply also in the private
+  part of an instance of a generic unit.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, February 24, 2015  6:03 PM
+
+> [ASIDE: I will say I am not thrilled with the use of the term
+> "immutable."
+
+I agree with your reasons for being unthrilled.
+
+> ...Perhaps
+> "inalterable"?
+
+I don't think that's a word.  "unalterable", perhaps.
+Or "static" (inspired by J-P's suggestion of "final").  ;-) Or
+"unutterable"?  ;-)  ;-)
+
+More seriously, do we really need yet more magic words?  Can't we just say
+"Blah shall not be redefined..." or some such?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, February 24, 2015  6:25 PM
+
+I don't think that would work. Tucker wants to move this bunch of rules into
+13.1.1 rather than repeating them in each place (three places currently, but
+it's easy to imagine more in future aspects). In order for that to make any
+sense at all, we need some sort of term so the reader knows that the rules are
+incomplete at the point of definition and that they need to look in 13.1.1 to
+find the rest.
+
+In the absence of such a term, I'd rather just duplicate the rules as Steve
+originally had done rather than to put some of the rules somewhere that no one
+would look naturally. But I agree that's a future maintenance hazard.
+
+More generally, blanket rules really only work when they apply to everything (as
+in the resolution of aspect specifications), not as well in cases like this when
+they apply to a narrowly defined subset of something. I'm rather dubious that
+the blanket rules proposed in AI12-0153-1 are worth the effort, for example; if
+we did make the changes, a term would make the fact that they apply clearer.
+(Not that I want to come up with such a term.) We'll probably discuss this more
+on Thursday.
+
+****************************************************************
+
+From: Vincent Celier
+Sent: Tuesday, February 24, 2015  6:56 PM
+
+>> ...Perhaps
+>> >"inalterable"?
+> I don't think that's a word.  "unalterable", perhaps.
+
+I believe inalterable is a word, bot in French and in English.
+
+http://en.wiktionary.org/wiki/inalterable
+
+****************************************************************
+
+From: Dr. Joyce L Tokar
+Sent: Tuesday, February 24, 2015  8:20 PM
+
+Both are words....inalterable is the older version (1535-45) whereas unalterable
+is from 1610-1615.  They have the same meaning and both are found in common
+usage in the English language today.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, February 24, 2015  9:25 PM
+
+>> Here is my take on consolidating the rules relating to "immutable"
+>> aspects.
+>
+> A quick glance at this suggests that you didn't update the discussion,
+> which is talking about "new legality rules added to 4.1.5, 4.1.6, and
+> 5.5.1", and then talks about the "first" and "second" new rule. (With
+> your wording, there is only one rule in each subclause.) I suspect
+> that the discussion is really now about the rules in the new blanket
+> definition.
+
+Yes, sorry about that.  Without looking I presumed the discussion didn't need
+change, since I was just moving the rules around.  But clearly I was wrong!
+
+>> [ASIDE: I will say I am not thrilled with the use of the term
+>> "immutable."  Perhaps "inalterable"?
+
+> ... I get forms of fixed ...
+
+How about fixed and floating aspects? ;-)
+
+> "Permanent aspect" might work; "eternal aspect" maybe not. ;-)
+
+"Permanent" isn't too bad, but the opposite of "permanent" is typically
+"temporary," and that doesn't really make sense.
+
+So I think I would still suggest "inalterable."  Reminds one a bit of
+"inalienable" ... [actually, an interesting side story there -- Thomas Jefferson
+wrote "inalienable" in his original version of the Declaration of Independence,
+but John Adams changed it to "unalienable" when he copied it over for the final
+printing -- tnx to ushistory.org].
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, February 24, 2015  9:27 PM
+
+>> Here is my take on consolidating the rules relating to "immutable"
+>> aspects.
+>
+> Another oddity: you removed the generic boilerplate from the new text
+> in 4.1.5, because you included it in the definition of "immutable
+> aspect". But you left it in the new text for 5.5.1. I would have
+> expected 4.1.5 and 5.5.1 to be treated the same.
+
+Oops again!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, February 25, 2015  4:28 AM
+
+> Both are words....inalterable is the older version (1535-45) whereas
+> unalterable is from 1610-1615.  They have the same meaning and both
+> are found in common usage in the English language today.
+
+To my british ear, unalterable sounds much preferable, though inalterable wins
+the google race by a factor of 9.
+
+****************************************************************
+
+From: John Barnes
+Sent: Wednesday, February 25, 2015  5:52 AM
+
+Oxford seems to suggest that unalterable is preferrred in that it defines
+inalterable as unalterable.
+
+It also notes that unaltered means not castrated!
+
+Fowler is not much help. It says that historically one would expect un with
+English words and in with Latin words but then says it's a mess. Note assymetric
+pairs such as unstable and instability.
+
+I would go for un I think.  Hmm. Not sure.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Wednesday, February 25, 2015  9:11 AM
+
+Would one normally alter their aspects? Maybe its just me, but I find this to be
+a somewhat odd thing to say. I had to alter the Pre'Class aspect of my derived
+class. I think one would normally speak of either replacing or modifying an
+aspect, so irreplaceable or unmodifiable seems a closer fit.
+
+How important is it to be a word that you can find in the dictionary?
+
+This property is tied to derivation so it seems it might be clearer and more
+precise to say unsupersedable, however that does not appear to be a word even
+though its base, supersede is an English word.
+
+In any case, I am not married to any of these choices, so I suppose one might
+say I am unaltarable to any of these choices.
+
+If I had to choose though, I think I would go with irreplaceable.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 25, 2015  1:44 PM
+
+Here is an update to AI12-0138, switching to "unalterable" term, and fixing the
+discussion.  I also changed the statements about "blah is an unalterable aspect"
+to be Static Semantics, as the legality rules have moved to 13.1.1.
+
+By the way, another possible alternative I thought of to "unalterable" is
+"stable."
+
+****************************************************************
+
+From: Steve Baird
+Sent: Wednesday, February 25, 2015  3:09 PM
+
+> Here is an update to AI12-0138, switching to "unalterable" term,
+
+We could also consider "irrevocable ", "irrevocably specified", or "binding".
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 25, 2015  3:49 PM
+
+I like "irrevocable."  Alternatively, given the definition of "overridden" given
+in 13.1(15/3) for aspects, I think "non-overridable" would convey exactly the
+correct semantics.  Is there some reason we didn't like that term?  It seems
+sort of obviously correct in hindsight.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Wednesday, February 25, 2015  4:04 PM
+
+I agree, "non-overridable" is clearer than anything else we've discussed.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, February 25, 2015  4:07 PM
+
+Especially if this is all about overriding, rather than altering per se! I like
+this suggestion.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 25, 2015  4:11 PM
+
+> >> Here is an update to AI12-0138, switching to "unalterable" term,
+> >
+> > We could also consider "irrevocable ", "irrevocably specified", or
+> > "binding".
+>
+> I like "irrevocable."  Alternatively, given the definition of
+> "overridden" given in
+> 13.1(15/3) for aspects, I think "non-overridable" would convey exactly
+> the correct semantics.  Is there some reason we didn't like that term?
+> It seems sort of obviously correct in hindsight.
+
+Probably because 13.1(15) is not intended to define a term "overridden"; it's
+not in italics, it's not indexed, etc. I thought that was an "English" use of
+"overridden". (Or perhaps I never thought of it at all.)
+
+Indeed, we had an entire AI on this topic: "AI12-0104-1  Overriding an aspect is
+undefined", where we got rid of wording that talked about "overriding" an
+aspect, because no such thing was thought to be defined.
+
+Either we didn't think 13.1(15) defined the term, or no one even found that
+reference.
+
+To change course yet again would require changing 13.1(15) to italicize the
+term, and then revisiting the various AIs (I think there may have been more) to
+determine what changes need to be made to them. Certainly not something that we
+should do tonight nor during tomorrow's meeting [we could decide intent at
+most]. We'd have to have either an additional phone meeting or a bunch of letter
+ballots to deal with that afterwards.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 25, 2015  4:21 PM
+
+> > Alternatively, given the definition of "overridden" given in
+> > 13.1(15/3) for aspects, I think "non-overridable" would convey
+> > exactly the correct semantics.  Is there some reason we didn't like
+> > that term? It seems sort of obviously correct in hindsight.
+>
+> I agree, "non-overridable" is clearer than anything else we've
+> discussed.
+
+[I want to scream, but I'm afraid that it might bother my neighbors in this
+office building. :-)]
+
+Surely it's "clearer". If we thought it meant anything, we never would have had
+any of these AIs in the first place, because the original Ada 2012 wording said
+that most of these aspects were not overriddable (without explaining the
+consequences).
+
+But Ed asked what that meant, since "overriding an aspect" isn't defined.
+
+So we got rid of that wording, especially as it was marked as redundant.
+
+But that caused Steve to ask one of his typical questions about generic derived
+types and these aspects. Which I noted was more general than the obscure case he
+asked about.
+
+Thus some wording was proposed to plug the hole.
+
+Which led to an argument about the term to use.
+
+Which now seems to have settled on virtually the original wording (with some
+additional rules to back it up).
+
+Once we adopt that, we can start the whole chain over again. "There's a hole in
+the bucket, a hole!!!" - Ancient folk song.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 25, 2015  4:26 PM
+
+>> ... Alternatively, given the definition of "overridden" given in
+>> 13.1(15/3) for aspects, I think "non-overridable" would convey
+>> exactly the correct semantics.  Is there some reason we didn't like
+>> that term?  It seems sort of obviously correct in hindsight.
+>
+> Probably because 13.1(15) is not intended to define a term
+> "overridden"; it's not in italics, it's not indexed, etc. I thought that was
+> an "English" use of "overridden". (Or perhaps I never thought of it at all.)
+>
+> Indeed, we had an entire AI on this topic: "AI12-0104-1  Overriding an
+> aspect is undefined", where we got rid of wording that talked about
+> "overriding" an aspect, because no such thing was thought to be defined.
+
+Interesting!  A bit of history my brain conveniently forgot.
+
+> Either we didn't think 13.1(15) defined the term, or no one even found
+> that reference.
+>
+> To change course yet again would require changing 13.1(15) to
+> italicize the term, and then revisiting the various AIs (I think there
+> may have been more) to determine what changes need to be made to them.
+> Certainly not something that we should do tonight nor during
+> tomorrow's meeting [we could decide intent at most]. We'd have to have
+> either an additional phone meeting or a bunch of letter ballots to deal with
+> that afterwards.
+
+I think the term "overriding" for aspects is intuitive, and I can't remember why
+we chose to abandon it.  So I would be in favor of enshrining "overriding an
+aspect" as an official term, and then use it where appropriate.
+
+And yes, I can sympathize with your desire to scream... ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 25, 2015  4:28 PM
+
+> > I agree, "non-overridable" is clearer than anything else we've
+> > discussed.
+>
+> Especially if this is all about overriding, rather than altering per
+> se! I like this suggestion.
+
+To turn to a technical objection, it seems to me that that could be confusing.
+After all, the entity designated by the aspect can be overridden or overloaded
+(for Constant_Indexing/Variable_Indexing in particular), what you can't do is
+change (alter?) the entity designated. We've generally not used the term
+"override" with aspects (other than the one sentence Tuck dug up); they are
+outright replaced.
+
+Perhaps that is something that we should rethink, but I don't think it's a good
+idea to do that at 23:58 in this particular process.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 25, 2015  4:35 PM
+
+> To turn to a technical objection, it seems to me that that could be
+> confusing. After all, the entity designated by the aspect can be
+> overridden or overloaded (for Constant_Indexing/Variable_Indexing in
+> particular), what you can't do is change (alter?) the entity
+> designated. We've generally not used the term "override" with aspects
+> (other than the one sentence Tuck dug up); they are outright replaced.
+
+Actually, the term "overridden" appears in 13.1(15.1/3) as well, and in AARM
+paragraphs 13.1(15.a, 15.b.1/3).
+
+> Perhaps that is something that we should rethink, but I don't think
+> it's a good idea to do that at 23:58 in this particular process.
+
+Not sure I agree.  If we are introducing a new term at 23:58, that seems worse
+to me. Straightening out the usage of a term that already appears in the
+standard makes perfect sense in a corrigendum, especially if it makes intuitive
+sense to most folks.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 25, 2015  4:53 PM
+
+...
+> > Perhaps that is something that we should rethink, but I don't think
+> > it's a good idea to do that at 23:58 in this particular process.
+>
+> Not sure I agree.  If we are introducing a new term at 23:58, that
+> seems worse to me.
+> Straightening out the usage of a term that already appears in the
+> standard makes perfect sense in a corrigendum, especially if it makes
+> intuitive sense to most folks.
+
+I'm mostly against re-introducing a term that was thought not to be defined at
+23:58, with an unspecified scope of changes to accommodate that. (That is,
+voting tomorrow to have the editor straighten it out without an additional
+vote.) That's something we should think through carefully to ensure that we
+haven't introduced additional problems, not do as a rush.
+
+If you had made this suggestion on Friday, I still would have screamed, but
+there would have been time to deal with it. As it is, I need to post the agenda
+in the next couple of hours (and I still have to finish AI12-0152-1) so that our
+west coast members have a chance to read the AIs before tomorrow's meeting. (I
+don't think anyone should be forced to get up at 6 am their time to be prepared
+for an ARG meeting.)
+
+I still think we'll need to introduce "nonoverriddable aspect" as a term, since
+there is a bunch of specific Legality Rules triggered. (Note: I don't think
+there is a hyphen in here, as this is a new term and the anti-hyphen forces won
+that debate -- we only use hyphens after "non" in words already extensive used
+in the Standard.) That's not something we would want to have people figure out
+by guessing what the consequences are. :-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 25, 2015  5:15 PM
+
+...
+> If you had made this suggestion on Friday, I still would have
+> screamed, but there would have been time to deal with it. As it is, I
+> need to post the agenda in the next couple of hours (and I still have
+> to finish AI12-0152-1) so that our west coast members have a chance to
+> read the AIs before tomorrow's meeting. (I don't think anyone should
+> be forced to get up at 6 am their time to be prepared for an ARG
+> meeting.)
+
+I agree we should not try to solve this entire problem tomorrow.  But I do think
+we should address it in the upcoming Corrigendum.
+
+> I still think we'll need to introduce "nonoverriddable aspect" as a
+> term, since there is a bunch of specific Legality Rules triggered.
+
+Yes, I agree with that.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 25, 2015  5:38 PM
+
+> Actually, the term "overridden" appears in 13.1(15.1/3) as well, and
+> in AARM paragraphs 13.1(15.a, 15.b.1/3).
+
+True enough, but the other normative paragraph is a mirror of 13.1(15/3), and
+the appearance in the associated notes isn't very compelling, either.
+
+I probably should have said that we don't use "overriding an aspect" in any
+language rules, so far as I can remember; that's probably why we never defined
+it as a term.
+
+> > Perhaps that is something that we should rethink, but I don't think
+> > it's a good idea to do that at 23:58 in this particular process.
+>
+> Not sure I agree.  If we are introducing a new term at 23:58, that
+> seems worse to me.
+> Straightening out the usage of a term that already appears in the
+> standard makes perfect sense in a corrigendum, especially if it makes
+> intuitive sense to most folks.
+
+I think I prefer "irrevocable" as Steve suggested, because it has the closest
+connotation to the intended meaning (you can specify it once but not change it).
+I think "nonoverridable aspect" is likely to be confused with not being able to
+override the specified subprogram, which is definitely not what we mean.
+
+But I don't think the exact term matters that much; making sure that the rules
+are well-defined matters more.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent