Re: Is this expected behavior or not

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1hvv2kd9smnfx.6spgz9thd1mh$.dlg@40tude.net...
...
>> That might be less of a problem than you might think; the 'Read and 
>> 'Write
>> should handle the Octet-view while the type as-defined handles the
>> Array-of-[[Wide_]Wide_]Character view.
>
>That would make string tagged, which in turn would imply certain
>representation [embedded tag] and forced by-reference semantics. The
>consequences are far reaching, e.g. you would have to drop slices etc.

For string, requiring by-reference would have little practical effect, as 
almost all compilers pass strings by-reference anyway. There is no OOP-way 
to make slicing work, since slices are by definition references (in C-terms, 
they're an l-value), and since the representations have to vary, that isn't 
going to be possible.

My rough proposed Root_String_Type would be an abstract tagged type, but it 
wouldn't provide slices directly (it would provide functions for that 
purpose). But that's OK, because such a construct would have to be alongside 
the existing string types; we can't replace or change them in any 
significant way and I think that means we'll have to start over.

...
> This is again a key issue. Ada often conflates interface and
> representation/implementation. This must be fixed. But I am not even
> allowed to name
>
>   subtype Positive is Integer range 1..Integer'Last;
>
> a type. What would happed if I asked to be able to provide an alternative
> representation for Positive? To disallow unary minus?

That's easy: nothing would happen. Compatibility with existing code almost 
always has priority. If you can describe the changes in terms of the 
existing semantics, then you might have a chance, but if you invent your own 
terminology and propose to throw out the existing rules, no one is going to 
pay much attention. Even if you are right (and you may very well be right), 
it is just too likely to introduce intolerable incompatibilities.

...
> I presume that back in 90's there was too much opposition to overhaul the
> type system. Tagged types were added to the existing types, while one
> should have made classes and interfaces fundamental to all types. We got 
> an
> outbuilding instead of new fundament. [We must be happy that Taft managed
> to pressure for at least this change.]

You do know that the original Ada 9x design was much like you are 
describing, with 'Class for all types? 'Class for untagged types eventually 
got dropped because of various semantics issues (mainly, they just worked 
differently than the tagged version, and that was thought to be 
confusing) -- and when people thought that Ada 9x was just too large and 
stuff had to go, that was one of the first.

Of course, for composite types, almost everything should be tagged and 
controlled (there would have to be a critical memory usage reason to avoid 
that), and in that case everything works sanely. (Even indexing, given the 
new Ada 2012 features). So we're mostly talking about scalar type 'Class (we 
don't need any more anonymous access types of any kind, and they're 
essentially structural equivalence as it is, so 'Class would buy very little 
there).

I think the more interesting thing is that we've never brought it back. It 
seems that we haven't seen any truly compelling uses for the idea, because 
if we had, I'm sure it would have come back in Ada 2005 or Ada 2012.

                                              Randy.