Re: What would you like in Ada202X?

["Randy Brukardt" <randy@rrsoftware.com>]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:a12psmFskuU1@mid.individual.net...
> On 12-05-09 01:22 , Randy Brukardt wrote:
>> "Niklas Holsti"<niklas.holsti@tidorum.invalid>  wrote in message
>> news:a0rsroFp8lU1@mid.individual.net...
>>> On 12-05-08 03:48 , Randy Brukardt wrote:
>> ...
>> The details are different, but the basic idea (adding more literals) is
>> unchanged. And the use is in adding more literals, the details on exactly
>> how you do that are much less important.
>
> Perhaps I did not describe it well, but I am surprised that you don't see 
> more difference between "widening" and "deepening". Note that:
>
> - The "widening" extension only adds literals. The derived type has all 
> literals of the parent type, plus the added literals.
>
> - The "deepening" extension *replaces* some parent literals with new 
> literals. The derived type need not have any literals in common with the 
> parent type. But each parent-type literal corresponds to a range of 
> derived-type literals.
>
> A big difference is that for "widening", there is a natural conversion 
> (embedding, really) from the parent type to the derived type, while for 
> "deepening" the natural conversion goes the other way, from the derived 
> type to the parent type.

You are thinking like a language lawyer, much less like a user (something 
I'm often accused of!). I'm not paying all that much attention to the 
details of your proposal, but rather trying to look at it as a user would. 
In that case, both mechanisms give a way to add/change enumeration literals 
for an existing enumeration type. I think that's the capability that users 
would want -- and I doubt that they care particularly much how it is 
accomplished.

Of course, the details do matter at some point, but given that it's a number 
of years before any of this stuff will be worked on very seriously, I'm 
trying to look at the broad view now.

...
>>>> but to be really useful, we
>>>> need the equivalent of class-wide operations.
>>>
>>> That is the main question: do we?
>>
>> We need class-wide operations for Integer and Float and (especially) 
>> String,
>> so it's hard to imagine how we could avoid needing them for such an
>> enumeration!
>>
>> For example:
>>                Put (X : in Root_Integer'Class);
>> is much more useable than a generic that you have to instantiation for 
>> each
>> kind of type. (Some operations really do cross-cut types.)
>
> Ah, I didn't realise that you meant such a radical enlargement of the 
> present tagged-type class-wide programming.

If we suddenly have class-wide programming for enumerations, it would be mad 
to not allow it for other, similar types.

> Is there an AI on that? I looked for one, but did not find any.

Not really, although I mentioned an off-the-wall proposal for Strings that 
in an AI in another message from Wednesday.

...
>>> It seems to me that adding class-wide operations would force to
>>> use some kind of tags, call by reference, and view conversions, and then
>>> it becomes so similar to tagged types that it is not worth it.
>>
>> Umm, that's when it *does* become worth it. The problem is untagged types
>> are pretty hard to use.
>
> Do you mean they are hard to use in current Ada, or hard to use with 
> class-wide operations in the future Ada?

I was thinking of derived untagged types; I should have said that.

The issue is that there is virtually no difference between a derived type 
and two unrelated types with conversion functions. If you call the 
conversion functions "+" (as some people recommend), you're required to 
write one whole additional character when using two unrelated types. It's 
hard to imagine designing the huge mechanism of derived types (with all of 
its weird problems and compatibility issues) in order to say typing one 
character per use. (One could even say that the extra typing makes the 
program more understandable, I'm not sure I'd go that far.)

The only thing that you can get from derived types that can't be done any 
other way is inherit operations (and their interfaces). And that's just 
short of useless in Ada; the only use you can make of that is via generic 
derived types. (Moreover, once you add operations to untagged derived types, 
you can no longer specify their representation, meaning that using them 
forces you to give up another key Ada feature.)

That led me to say:

...
>>> I think the idea of "deepened" enumeration types is worth pursuing only 
>>> if
>>> it is useful without class-wide operations.
>>
>> Then don't bother. IMHO, at least.


                              Randy.