CVS difference for ai05s/ai05-0141-1.txt

Differences between 1.2 and version 1.3
Log of other versions for file ai05s/ai05-0141-1.txt

--- ai05s/ai05-0141-1.txt	2009/12/29 05:55:00	1.2
+++ ai05s/ai05-0141-1.txt	2010/01/09 03:16:00	1.3
@@ -43,7 +43,7 @@
 procedure Export_from_Pool (Pool : in out Root_Storage_Pool;
                             Storage_Address : in out Address) is null;
 
-procedure Add_to_Pool (Pool : in out Root_Storage_Pool;
+procedure Import_to_Pool (Pool : in out Root_Storage_Pool;
                        Storage_Address : in out Address) is null;
 
 [Editor's note: These rules (including the existing ones) are all under "Static
@@ -69,16 +69,16 @@
 
 Whenever a value of an access type is converted to another access type with a
 different (or unknown) storage pool, procedure Export_from_Pool is called for
-the source access type, and procedure Add_to_Pool is called for the target
+the source access type, and procedure Import_to_Pool is called for the target
 access type. Export_from_Pool takes a value returned by a call to Allocate or
-Add_to_Pool for the pool and returns the address of the associated memory.
-Add_to_Pool takes the address of memory of an object and returns an appropriate
-value. Add_to_Pool is also called for an access value created by an Access or
+Import_to_Pool for the pool and returns the address of the associated memory.
+Import_to_Pool takes the address of memory of an object and returns an appropriate
+value. Import_to_Pool is also called for an access value created by an Access or
 Unchecked_Access attribute. Any exceptions propagated by these routines are
 propagated by the conversion or attribute.
 
 [Perhaps we should say that a standard storage pool has Dereference,
-Add_to_Pool, and Export_from_Pool procedures that do not propagate any
+Import_to_Pool, and Export_from_Pool procedures that do not propagate any
 exceptions. Preferably, they would be null procedures, but we don't need to
 guarantee that.]
 
@@ -189,7 +189,7 @@
 
 [C] A version of Address_to_Access_Conversions could be added that would take a
     formal type rather than defining the access type directly. This would be
-    defined to call Export_from_Pool and Add_to_Pool appropriately.
+    defined to call Export_from_Pool and Import_to_Pool appropriately.
 
 [D] An additional routine End_Dereference
 
@@ -215,7 +215,7 @@
                           Access_Value : in Address) return Address;
 
 But note that the pool needs to be modifiable (so a restriction to in parameters
-only would be very annoying, especially for Add_to_Pool which certainly needs to
+only would be very annoying, especially for Import_to_Pool which certainly needs to
 add the address to a table if it is making handles for all values). Using
 anonymous access parameters would be theorically cause infinite regression, as
 these routines are *defining* the dynamic semantics of access values.
@@ -279,8 +279,8 @@
     function Export_from_Pool (Pool : in out Root_Storage_Pool;
                                Value : Access_Value) return Address is identity (2);
 
-    function Add_to_Pool (Pool : in out Root_Storage_Pool;
-                          Storage_Address : Address) return Access_Value is identity (2);
+    function Import_to_Pool (Pool : in out Root_Storage_Pool;
+                             Storage_Address : Address) return Access_Value is identity (2);
 
  private
    ... -- not specified by the language
@@ -399,21 +399,21 @@
       Dereference (Pool, Storage_Address); -- Nothing different here.
     end Export_from_Pool;
 
-    procedure Add_to_Pool (Pool : in out Checked_Storage_Pool;
+    procedure Import_to_Pool (Pool : in out Checked_Storage_Pool;
                            Storage_Address : in out Address) is
     begin
       if Last_Allocated = Allocated_Addresses'Last then raise Storage_Error; end if;
       Last_Allocated := Last_Allocated + 1;
       Allocated_Addresses(Last_Allocated) := Storage_Address;
       Storage_Address := Address(Last_Allocated);
-    end Add_to_Pool;
+    end Import_to_Pool;
 
   end Checked_Pool;
 
 Hopefully, a real pool would have a way to allocate more than 1000 elements -
 expanding the array or something. It could also check for deallocation of items
 not allocated from the pool by adding a flag to each element that would be set
-by Add_to_Pool, and raising an exception if that flag is set for the address
+by Import_to_Pool, and raising an exception if that flag is set for the address
 that is deallocated. The global objects also should be inside of the pool object
 (so that there can be multiple such objects).
 
@@ -459,7 +459,7 @@
       -- would have to be locked for the duration of the program - that
       -- could be done instead).
 
-    procedure Add_to_Pool (Pool : in out Persisent_Pool;
+    procedure Import_to_Pool (Pool : in out Persisent_Pool;
                            Storage_Address : in out Address);
       -- Raise Program_Error (unless we want to make ordinary access
       -- objects persistent).
@@ -504,10 +504,10 @@
 value pair is still needed. But the new pool operations could be used to make it
 impossible to use the access value after its lock has been freed.
 
-The pool would use handles to the objects. The Add_to_Pool operation would
+The pool would use handles to the objects. The Import_to_Pool operation would
 register an object and return a useful handle. The Export_from_Pool operation
 would unconditionally raise an exception, preventing conversion to other access
-types. Dereference would return the address of the object The pool also would
+types. Dereference would return the address of the object. The pool also would
 define an End_Dereference operation that would be called by the finalization
 routine of the returned lock/access object. This operation would mark the handle
 as invalid, so that any subsequent Dereference operation would raise an

Questions? Ask the ACAA Technical Agent