Re: Is this expected behavior or not

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 25 Mar 2013 17:58:26 -0500, Randy Brukardt wrote:

> "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).

OK, the representation would be for type-specific string objects:

   bounds + pointer

and for class-wide string objects:

   tag + bounds + pointer

>>>>> 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.

Why is it junk? There is nothing wrong with String, Wide_String,
Wide_Wide_String. They should stay.

Unbounded_String is indeed junk, but after adding an array interface to it
= putting it into the same hierarchy it would perfectly serve the purpose.

>> 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.

Why? The effect is limited strictly to T'Class objects, which presently do
not exist.

> (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.)

This is a different problem. I think the model is that string and other
literals would become primitive operations. Upon inheritance in the class
sense, they should be overridden or else dropped. There should be some
syntax invented for handling literals, e.g, some factory operation etc. An
alternative is having literals class-wide, which roughly corresponds to
existing Universal_String approach. In both cases you might wish to add
some preference rules [we already have some] to keep it compatible and
slash ambiguities. It would be worth to consider a possibility for the user
to control such preference rules and to have user-defined literals in
general.

> 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.

Yes, but untagged types in the model I have in mind will remain independent
types, they would not suddenly become Ada-subtypes, if you mean that. So

   subtype S is String ...;
   type Q is new String ...;

would have different semantics, just like they do for tagged types already.

> And dispatching is incompatible with untagged types, simply because Ada 83 
> got inheritance horribly wrong, and we're stuck with that.

I disagree. It seems fully compatible with Ada 83 because T'Class would be
a distinct type with objects of that type. It is orthogonal to
Ada-subtypes. You will not dispatch on Positive vs. Integer, these will
reman specific [sub]types. In order to dispatch you will need a class-wide
object of the type Integer'Class (which will be strictly same as
Positive'Class, except, possibly, the constraint). That object will have
the representation tag + value. For Integer and Positive objects nothing
changes. We might consider redefining some existing operations to become
class-wide in some arguments, but that is another story.

>>>> 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?

Target and handle types usually implement some public interface. E.g.

   type File_Access is limited interface;
   procedure Write (File : in out File_Access; Data : ...) is abstract;
   ...

Somewhere else

   type File_Descriptor is ... limited ... and File_Access ...;

Somewhere else

   type File_Handle is ... and File_Access ...;

>>> 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.

But this is the only choice if your checks are dynamic. If you don't like
testing then you should understand why I don't buy dynamic checks [mis]used
to detect 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.

So, I need an AI system to parse compiler messages (of various vendors) on
top?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de