Re: Converting access values

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Upkeep" <aek@vib.usr.pu.ru> writes:

> 1) for literals:
> 
> for T'Literal_Conversion use F;
> 
> where F takes a literal (integer, string, etc) and returns T.

Yeah, something like that is what I had in mind.

> 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.

> 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.

> 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.
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);

- Bob