Re: Gem 39 - compiler specific?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 3 Sep 2009 10:27:57 -0700 (PDT), Adam Beneschan wrote:

> On Sep 3, 9:38�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Thu, 3 Sep 2009 08:26:50 -0700 (PDT), Adam Beneschan wrote:
>>> On Sep 3, 12:26�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>> wrote:
>>>> Skewed address is not a problem here. The problem is that
>>>> System.Address_To_Access_Conversions should take an access type as a
>>>> parameter rather than declare it new. This makes its use quite limited.
>>
>>> I don't see any limitation, at least where To_Pointer is concerned
>>> (which is what the above code needed to use). �If you declare an
>>> instance of this package for any object type T:
>>
>>> � type Convert_T_Access is new System.Address_To_Access_Conversions
>>> (T);
>>
>>> then an object of type Convert_T_Access.Object_Pointer can be
>>> converted to any access type whose designated type is T. �I checked
>>> through the legality rules in 4.6, and I couldn't find a way to
>>> declare an access-to-T type that you couldn't convert an
>>> Object_Pointer to. �Thus, if you have any access type
>>
>>> � type Acc_T is access T; �[or access all T, or access constant T]
>>
>>> you can convert an address Addr to an Acc_T by saying:
>>
>>> � Acc_T (Convert_T_Access.To_Pointer (Addr))
>>
>> But Acc_T is a pool-specific access, while Address_To_Access_Conversions
>> creates a general access type.
> 
> Sigh... I missed that---you can't convert a general access type to a
> pool-specific one.  4.6 can be hard to follow, the way it's organized,
> but that's not a good excuse.  I've read it enough times that I should
> know better.
> 
> However, one could make that case that if you declare a pool-specific
> access type, then by definition it should point to something that's in
> a pool; and that if you want an access that could point to an
> arbitrary address (as Access_To_Address_Conversions would let you do),
> you should use a general access type.

Address may have some specific representation when points into a pool. The
idea of Access_To_Address_Conversions is to provide programmer a bit more
safety than Unchecked_Conversion would.

Why do we have Access_To_Address_Conversions? Why not to require
Unchecked_Conversion to do all the checks Access_To_Address_Conversions
does in the corresponding cases? I mean, there is no obvious reason why the
implementation of Access_To_Address_Conversions should be safer than one of
Unchecked_Conversion. The information the compiler has at the instantiation
point is just same.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de