Re: Is this expected behavior or not

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:a96esjwiniqy$.op3wh7x9wrsl.dlg@40tude.net...
> On Fri, 22 Mar 2013 21:33:02 -0500, Randy Brukardt wrote:
...
>> That doesn't necessarily mean copying of the data. If the designer
>> of the abstraction, have put in enough smarts to share representations --
>> after all,
>
> You should break your mental block. No shared representation, I want
> different representations for different string types.

I was talking about sharing representations of *different* objects of the 
same string type (for instance, a string variable and a slice of that 
variable - that case, sharing the data might be preferred to copying it). 
Not talking about different types here; of course, the whole point of 
changing anything here is to allow different representations of the data.

>>>> Slicing is already impossible for the case that we're talking about,
>>>
>>> ?
>>>
>>> Normal strings have slices and should continue to have them.
>>
>> Sure, but Root_String'Class is a separate type hierarchy.
>
> I see, yet another outhouse, also. Ada quickly becomes a shantytown...

Unifying old junk it's possible without serious breakage of existing code, 
which is intolerable. It's better to start over and obsolete the old stuff.


>>>> and
>>>> interface to foreign language already has to be done through special
>>>> types.
>>>
>>> Which should certainly be in the same class! There is no semantic reason
>>> why char_array should not be considered string.
>>
>> It won't work, semantically or implementation-wise. This is a total 
>> restart
>> of String semantics, and the old semantics will still exist (probably in
>> Annex J). There is no way to make the existing array semantics work like 
>> a
>> tagged type, and that is absolutely necessary for dispatching to work 
>> (even
>> if it isn't a "tagged type" in Ada terms).
>
> The way is to allow untagged T to have T'Class. This will preserve all
> semantics and all existing representations. Not even an explicit root type
> is needed, e.g. for char_array. The technique makes it possible to have
> ad-hoc supertypes, which would serve the purpose, e.g. you would define
> Put_Line on such a supertype and it will work for both String and
> char_array. Not a line changed in Standard or Interfaces.C.

Sounds great, but it won't work in practice. You'd introduce a lot of 
ambiguities and break existing code that way. (That's why 
Ada.Strings.Unbounded_String doesn't have string literals; we couldn't find 
any way to add them without making most existing code using the package 
ambiguous.)

Secondly, the inheritance and overriding of untagged types is much looser 
than the that of tagged types; you don't even have to use the same parameter 
modes. That's not going to be compatible with dispatching, so you would have 
to make quite a bit of existing types illegal if you want to truly support 
Untagged'Class. (We had to introduce such an incompatibility when we "fixed" 
equality for untagged record types, and it was very controversal. I doubt 
that we would risk going further.)

I'm also dubious that good code can be generated for such a model, but 
that's a secondary concern vs. the incompatibility.

...
...
>>> This is a totally bogus argument. OO imposes no overhead on specific
>>> types.
>>
>> That's kool-aid invented by the Ada 9x team. It's not remotely true,
>> especially as all usable OOP types have to be controlled.
>
> See above. T'Class for all types!

See above -- this model is likely impossible for Ada. (It might work fine in 
a new language, but that's irrelevant here.)

...
>> Why go further down a path to nowhere?
>
> Not even single step made so far. I see a lot of ad-hocks added recently
> which directly influence discrete types. All these aspects, attributes
> ('Read) are defined on discrete types as well. You are dragged down the
> path, looking backwards...

No choice. We can *add* new stuff, but changes to old stuff isn't possible. 
And dispatching is incompatible with untagged types, simply because Ada 83 
got inheritance horribly wrong, and we're stuck with that.


>>> How do I put such a reference in an array, for example? 4.1.5 would be
>>> extremely difficult to use for intended purpose.
>>
>> It's just a tagged object, do with it what you want. I don't see why you
>> think there is a problem.
>
> We will see. My prediction is that 4.1.5 will be very rarely used. Those
> who will try it, will have to fight with language limitations imposed by
> the design and then will drop it. Libraries based on it, will in turn
> become difficult to use for average programmers. Too much mental overhead,
> too many helper types (a bad OO-fest), too much time to find the package
> where the mess resides, too much efforts to understand why the compiler
> rejected obvious code...

Like generics, the expectation is that hardly anyone will need to understand 
how it works. Just use it and get the expected semantics. And the compiler 
shouldn't be rejecting any obvious code unless the definition is screwed up. 
(That's the fault of the guru who set it up, not the user.)

There are large parts of Ada that aren't really expected to be used by "mere 
mortals". Generics, storage pools, generalized references and indexes, 
iterators, etc. In all of these cases, they really exist to make library 
packages easier to use; most users will use these things without worrying 
too much about how they're implemented.

I originally had a different model for 4.1.5 (most custom rules), but we 
determined that most of rules we needed already existed in the language. So 
it ended up a bit more complex (using a discriminant) in order to have far 
fewer new rules. That's usually a preferred trade-off.

...
>>> You have a very specific use case in mind, namely containers. There is a
>>> whole world outside that, for which what you said is untrue, e.g. for
>>> smart pointers. The thing not only exposes access, it also exposes the 
>>> target
>>> type.
>>
>> You have to expose the target type in order to have strong typing. How 
>> could
>> you hide it and still make type checks?
>
> Why should target type be public?

How do you enforce strong typing without that being the case? If you don't 
know what the target is, how do you determine how the resulting object can 
be used? (The type being public doesn't mean that the *contents* of the type 
are public -- of course the target could be an Ada private type.) The whole 
point of this construct is to *dereference* a referential access (no special 
feature is needed to define a handle, after all, we've been doing that since 
the beginning of Ada time).

>> The ONLY reason that we need 4.1.5 is so that we can assign directly
>> into the target type.
>
> Yes, it is a hack designed for single use case.

There is no other need, everything else can be done with functions and 
procedures. Even this assignment can be done with a procedure, but such a 
procedure cannot compose or support extensions.

...
....
>> If you really wanted to go this way, you'd put all of those types in the
>> same class. (Having every possible advantage without any disadvantages is
>> impossible.) You are right about multiple dispatch in some cases, 
>> although
>> it's usually possible to layer those:
>>
>>     procedure Send (To : in out Register; Value : Data'Class);
>>
>> which is legal Ada.
>
> Sure, this is exactly how I do it. It bursts into dozens of generic
> packages and hundreds of their instances. Unless you propose to code all
> hundreds of combinations manually... How should I test THIS?

Testing is close to worthless. Ensure that the code is right in the first 
place (admittedly hard), and use a bit of testing for acceptance. Testing 
never proves any sort of correctness; all of the many thousands of hours of 
testing on our compiler never did anything to make it more reliable -- that 
all happened by better design. At best, the testing just prevented 
reintroduction of old bugs.

...
>> That's my point about static analysis. Such a tool should be able to 
>> prove
>> that the majority of run-time checks can't happen, and give you a list of
>> those remaining.
>
> I don't need any list. Should I send it to my customers? I need the 
> program
> fail to compile when writing analogue input.

Treat the list as failures if you must, and insist that it be empty before 
shipping. That's a reasonable approach in some environments. But I think 
you'll find it's too hard to accomplish, just like it's too hard to do 
complete code coverage (hard to test error handlers) and it's too hard to 
make everything generic. I'd rather prioritize such issues, and only worry 
about the ones in mainline code.

                                 Randy.