Re: Discriminant name must be alone

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

Robert A Duff wrote:

> However, I have run into a few cases where I would like to do what
> you're suggesting here.  For example, I wrote a "storage pool" type,
> where the private part defined the storage as an array of machine words.
> The allocated types were known to be always word aligned, and always a
> multiple of word size.  The array of words makes alignment easy, and the
> Allocate procedure can simply return 'Address of one of the array
> components.  But I wanted the client to specify the size in
> Storage_Elements.  So the array would have to be:
> 
>     Storage: Word_Array(0..(Size_In_Bytes-1)/4); -- Illegal!
> 
> where Size_In_Bytes is the discriminant.  Or something like that.
>
> I think the main problem with allowing that (besides what the AARM
> mentions) is that if you allow arbitrary expressions referring to
> discriminants, you have to worry about when that expression is
> evaluated.  Suppose that expression is "F(Size_In_Bytes)", where F is
> some function that might have side effects.  If it has side effects, it
> might return a different answer each time it's called.
> 
> I suppose one answer is to say that the expression is evaluated whenever
> a value of the record type is created.  The value of that expression
> must be saved as "dope" -- a hidden record component created by the
> compiler.  If it has side effects, that's the programmer's problem.
> This would be the first case where a compiler is required to store
> dope.  Some compilers store dope, but it's never required.
> 
> Another answer is, "forbid side effects in those expressions", so the
> compiler can evaluate those expressions whenever it likes.  Ada has no
> such mechanism, currently.  To provide such a mechanism, each function
> would have to declare (on the spec) what variables it meddles with --
> as in SPARK.  If the expression "Start_Ind + 10" is allowed, then surely
> you should be allowed to call a function that does "return Start_Ind +
> 10;".

There is a third answer: "user-defined constructors". Should you have a 
user-defined constructor for a discriminated type, you could evaluate its 
discriminants during object construction, which would have same effect as 
if they were expressions (with the arguments provided by the constructor's 
argument list).

User-defined constructors could also solve the "assignment problem", because 
an assignment can be easily generated out of copy-constructor.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de