Re: What would you like in Ada202X?

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

On 12-05-15 09:30 , Randy Brukardt wrote:
> "Niklas Holsti"<niklas.holsti@tidorum.invalid>  wrote in message
> news:a1ahq2F7e2U1@mid.individual.net...
>> On 12-05-10 03:47 , Randy Brukardt wrote:
>>> "Dmitry A. Kazakov"<mailbox@dmitry-kazakov.de>   wrote in message
>>> news:kl5nkc2s9tsx.61oqe3a9ogra.dlg@40tude.net...
>>>> On Tue, 08 May 2012 22:20:21 +0300, Niklas Holsti wrote:
>>>>> I would like to make the "deepening" derivation as similar as possible
>>>>> to the derivation of enumeration types in
>>>>
>>>> With the problems solved you will get enumeration extension for granted.
>>>> Your proposal rounds about how to generate conversion functions. You can
>>>> generate in-conversion, but cannot out-conversions. The case of plain
>>>> extension has the opposite problem: in-conversions are impossible. But
>>>> the
>>>> mechanics of all this is same: interface inheritance, delegation of some
>>>> inherited operations to the parent's body composed with a conversion.
>>>>
>>>> Semantically, there always will be some issue with conversions, because
>>>> any
>>>> non-trivial modification of a type, must break something. If it did not,
>>>> you would use the old type instead. It is not the language business, it
>>>> is
>>>> up to the programmer to resolve. The language should simply refuse to
>>>> automate suspicious cases forcing the programmer to intervene.
>>>
>>> Here I agree with Dmitry (but note that the mechanism he is talking about
>>> here has nothing to do with multiple inheritance; it works just fine with
>>> Ada 95 type derivation or something similar to that).
>>
>> I agree with Dmitry's and your rejection of automated but suspect
>> conversions, which is why I suggested not to inherit parent operations
>> that would need conversion from the parent enumeration type to the
>> "deepened" enumeration type. I could also accept the alternative to
>> inherit abstract versions of such parent operations, which would be more
>> useful for class-wide programming.
>>
>> But I don't see how a single programmer-defined conversion function from
>> the parent type to the deepened type could work in general, that is, how
>> the same conversion would be appropriate for all "out", "in out", and
>> function-return positions in all parent operations. And if different
>> conversion functions are needed for different operations/parameters, we
>> may as well choose "inherit as abstract" and require the programmer to
>> implement these operations for the derived type.
>
> "Conversion" is almost never a single function; indeed, Ada requires it to
> work both ways in most cases. In particular, if you have "out" parameters,
> you need a conversion from the parent to the child type, just like you need
> a conversion from the child to the parent to implement "in" parameters.

That is how it works in Ada now, yes. Well, except for the view 
conversions of tagged types et c., I would say.

>> For example, the function Ada.Directories.Current_Directory now returns
>> String; how would that, and other I/O functions that return String, be
>> handled? Would they return Root_String'Class?
>
> Yes, of course, there would be a version of everything that takes a String
> that would take a Root_String'Class.

Ok, that is consistent. The implementation of Ada.Directories on the 
current system decides which concrete kind of string is proper for this 
system, and returns such an object, but seen as Root_String'Class by the 
caller.

> (I don't think there are many routines
> that take "out" String parameters, because you can't change the size that
> way.)

But in general, how would "out" parameters of type Root_String'Class (or 
SomeType'Class) work? Of course the subprogram can call operations like 
Set_Char on the parameter to alter its value, but what about a 
whole-object assignment, Parameter := Value? I guess that must raise 
Constraint_Error if the new Value does not match the actual Parameter in 
type or discriminants.

> The problem is that the language doesn't provide the syntax to connect the
> "hand-built" conversions with the existing machinery of (sub)type
> conversion; I'm assuming that would be done if the conversion solution was
> intended to be used as a first-class technique.

Yes, I think I see what you mean.

> Specifically, when you "derive" a new type from an existing type, the idea
> is that you could give the derived type any declaration and representation
> you want (it wouldn't have to be related to the parent, with some limits),
> and you could then define conversion functions (always two) similarly to the
> way that streaming subprograms are defined. Inherited routines would use
> those conversions when conversions are needed (as already defined by the
> language). That would allow one to have very unrelated types be "related"
> via derivation.
>
> I'm not sure that it is good idea in general, but certainly it makes sense
> in limited cases

Same sentiments here (I assume by "limited cases" you don't mean 
"limited types" in the Ada sense). The main limitation, I think, is that 
the derived type cannot be much more "meaningful" -- that is, carry more 
information -- than the parent type; if it is, the conversion from 
parent to derived would have to supply the additional information, from 
nothing.

> (surely including your enumeration example).

I don't think so, because the "deepened" enumeration type has more 
information than the parent type. In the example I gave, the 
derived-type literals Read and Write convert to the parent-type literal 
Request, but the conversion back from Request to the derived type would 
have to choose either Read or Write, and it has no information to guide 
that choice.

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