Re: Converting access values

["Alexander E. Kopilovich" <aek@VB1162.spb.edu>]

Robert A Duff wrote:

> > 2) for array-indexing, constrained subtypes and case statements:
> > 
> > for T'As_Discrete use F;
> > 
> > where F takes an object of type T and returns a value of some discrete
> > type.
>
> I don't think that quite works.  For example, I don't see how it allows
> me to write a case statement on an expression of type
> Arbitrary_Range_Integer -- I can't merely convert it to Standard.Integer
> and do the case on that.

Well. I thought about the case where the expression at the top is of some
discrete type, and only particular branches are related to the private type.

But if the expression at the top is of the private type then there can be
ambiguity - generally there can be several different reductions of the
private type to different discrete types (that is, with separate "for...use"
statement for each). Therefore a particular reduction must be chosen for
the expression at the top - the corresponding discrete type must be given
there. I think that syntactically usual type conversion notation may be the
best choice there.

> > Naturally, there arises the question of static (that is, compile-time)
> > evaluation of those attributes (although they are sensible and useful
> > even without this opportunity).  Well, there may be some restrictions
> > for the functions that implement those attributes - that permit (or
> > facilitate static evaluation of these functions. And if those
> > restrictions aren't satisfied then compiler can issue a warning,
> > telling programmer that all relevant checks/transformations will be
> > done dynamically (this warning may be suppressed by appropriate
> > pragma).
>
> If I were designing such a language, I think I would place restrictions
> on the T'Literal_Conversion thing so that it *can* be evaluated at
> compile time.  Not a suppressable warning, but a normal legality rule.
>
> That's because I don't want an innocuous looking thing like:
>
>    123
>
> to be able to raise an exception at run time.  If there's something
> wrong with that literal, I want a compile-time error.

Well, I'm not sure about that, maybe you are right. But anyway, I think
that it will be useful to annotate this feature of a function - that it can
be evaluated in compile-time - explicitly, by use of 'constant' keyword:
 
  ... return constant T;

> > I'm not sure about wishes for aggregates, but I think that if all
> > objects of the type T have the same size and this size is statically
> > defined then the only problem may be that this size just is not known
> > in right place because of visibility rules. But if it is not visible
> > there then the use of access is essentially forced, because any other
> > solution will violate (directly or indirectly) encapsulation of the
> > private type to some degree.
>
> I've lost you there.  I don't see why it has anything to do with size.

Well, as I said, I was unsure about the wishes for the aggregates; I guessed
that you meant using an object of the private type as a member of a record,
and apparently this my guess was wrong - your "aggregate" was a verb, not
a noun -;) 

> I was thinking of something like:
>
>    for T'Aggregate use F;
>
> where F takes whatever parameters it likes, and does whatever it likes,
> and returns an object of type T.  Then:
>
>    X := (A, B, C);
>
> (I'd prefer [A, B, C], actually) would simply be a shorthand for:
>
>    X := F(A, B, C);

Well, no problem with it, except one: if F can do anything than why we are
thinking of it as of an "aggregation"? It is more like "computation" rather
than "aggregation".

I think that there should be some severe restrictions for F there, which
will justify use of the term and the notation. For example, there may be
following restriction:

   T is a record and the parameters of F correspond to the members of this
   record

But this seems, perhaps, too severe restriction... maybe it should be somehow
relaxed. It depends on intended uses, and I don't see them clear enough.




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia