Re: Ada.Locales pseudo-string types

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 12-08-08 10:32 , J-P. Rosen wrote:
> Le 08/08/2012 09:04, Niklas Holsti a �crit :
>> The rule does seem surprisingly rigid, for a value conversion. (The
>> Annotated RM does not explain or motivate it.) For a value conversion,
>> the default could be to convert element by element, and the compiler
>> could then optimize this conversion based on what it can deduce
>> statically about the matching of the source and target subtypes.
> One of the founding principles of Ada was "no hidden inefficiencies"
> (whether this has been achieved is another story). Since an array can
> have many elements, this could be quite costly.

This is understood. Whether this inefficiency is "hidden" is debatable,
of course.

> And of course, it would force pass-by-copy

I don't think so. If the source and target element subtypes statically
match, or match well enough that no element conversions are necessary
(as in the original Ada.Locales example), the compiled code could be the
same as compilers use now. In other cases, the compiler could create a
temporary array to hold the result of the conversion, and pass this
array by reference.

I admit that this could lead to cases where a small change in the types
makes the compiler switch from the fast, no-copy, pass-by-reference code
to the slower element-by-element copying code, which could cause a
surprising drop in performance. Users might want compilers to warn them
about such cases.

>> In the example, the compiler should be able to deduce that
>> element-by-element conversion is unnecessary since the source element
>> subtype is a subrange of the target element subtype.
> But if the conversion is used for an in-out parameter, it implies the
> opposite conversion - where nothing can be deduced.
> 
> And you don't want a special rule that works only for in parameters,

"In" parameters already have special rules, since conversions for "in"
parameters are considered value conversions rather than view conversions.

> and only with compilers that pass arrays by copy, would you?

So the movation for the present static-match rule is that it makes it
simple for compilers always to pass arrays by reference, even when the
array is the result of a type conversion. (I suppose it is a quibble to
point out that a compiler is nevertheless not forced to pass by
reference.) But the rule is still stronger than necessary.

For value conversions, including "in" parameters, the exact match could
be replaced by a static check that the constraints on the source
elements are the same as or stronger than those on the target elements.
This would allow Ada.Text_IO.Put (String (Some_Country_Code)).

For "out" parameters, there could be a static check that the constraints
on the actual (source) array elements are the same as or weaker than
those on the formal (target) array elements.

For "in out" parameters, the present static-match rule would be kept, as
the logical conjunction of the "in" and "out" rules.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .