Re: Is this expected behavior or not

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1raubw1sk48ca$.69rdgczvnnf.dlg@40tude.net...
> On Tue, 19 Mar 2013 16:19:54 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:vo941i7imo8t$.1jjjox9r1hkqa.dlg@40tude.net...
>
>>> It is well possible. Consider tag a constraint as array bounds are. 
>>> Allow
>>> constraints (=discriminants) passed independently as compilers already 
>>> do
>>> for array bounds. This gives you array interfaces while keeping arrays 
>>> as
>>> they are, plain arrays.
>>
>> No, it's not possible. In order to solve the string problem, we have to
>> decouple the representation and the interface. But for slices, you have 
>> to
>> know the representation in order to be able to pass it meaningfully.
>
> You pass dope and reference.

You have to know the representation of what you reference in order to access 
it, even after the "dope and reference". The only way to handle differing 
representations is to pass accessor thunks along with the dope, but that 
only allows you to access individual elements. Turning every slice reference 
into a loop of thunk calls is just way to complicated for the usage (which 
is pretty rare, especially if packages like Unbounded_Strings are made 
class-wide).

>> Moreover, the representation is not necessarily an array (UTF-8 encoding 
>> is
>> not a normal array if you are using the character interface).
>
> In the dope you have type tag to handle class-wide instances. You will
> dispatch to the body which implements indexing for UTF-8 encoded arrays of
> characters.

If any dispatching is involved, the syntax ought to be that of a function 
call. That allows indexing but not slicing.

Even if you are willing to confuse users with implicit dispatching, you're 
also talking about turning every slice reference into a loop. The extra 
complication would be intolerable for most vendors.

>>>> My rough proposed Root_String_Type would be an abstract tagged type,
>>>
>>> I definitely don't want strings tagged.
>>
>> Then forget it. All composite types ought to be tagged; the root of the
>> existing problem is that arrays aren't tagged.
>
> If you use "tagged" in RM sense as a class of types which a tag embedded
> into the representation, then no. That is not the problem and I don't want
> arrays to have tag. I want array interfaces and an ability to have objects
> of the type A'Class where A is an array type. The representation of 
> A'Class
> will have tag. The representation of A will not.

Why do you care? String objects are a lot bigger than a tag, so it can't be 
a memory usage concern. The only other place it could possibly matter is 
I/O. But for package like Text_IO, a tag and dispatching is exactly what you 
want, and for 98% of strings, that's what they ultimately get used for. For 
streaming and the like, the representation does not include the tag if you 
stream a specific type. So what's the problem??

Removing a tag from an object is an optimization; I believe every object 
should have a tag and it's up to the compiler how to implement it. It's 
really none of your (the programmer's) business (in the absence of 
representation clauses).

...
>> I don't think we
>> need 'Class for access types,
>
> You need them because access types shall implement "access interface." We
> need access interface for user-defined referential types.

Ada 2012 has user-defined referential types. You can do everything you need 
with plain-old tagged types.

>> because the effect is essentially the same as
>> what we already have for anonymous access types
>
> I don't see why. I want to be able to declare my own type as an access
> type:
>
>   type Handle is private access T;
> private
>   type Handle is record
>       Connection : DB_Connection_Handle;
>       Table         : Unbounded_String;
>       ... -- etc
>   end record;
>
> with the semantics of new, Free, dereferencing defined as I wish.

You can do the latter two in Ada 2012 as it stands; the first can easily be 
simulated with a constructor function. (Oh, that's right, you can't stand 
constructor functions.)

But in any case, this is a bad idea. You don't want to explicitly handle 
memory management in modern programs. Do it under the covers somewhere (like 
in the containers packages); do *not* expose access types.

> And I
> want to be able to write a class-wide subprogram which would take both
> Handle and some plain access type as a parameter.

As I said, no new code should be exposing raw access types. Something like 
the container Cursor type is a much better way to handle the need for 
referential semantics.

...
>> For someone that hates generics, why would you have so many?
>
> I have:
>
> 1. I/O modes of input, output, duplex;

Seems like a runtime parameter, not a compile-time one. (i.e. Mode in the 
I/O packages).

> 2. Specific values of types: Integer_n, Unsigned_n, String, Wide_String, 
> IEEE_Float_n;

Yes, of course, this is the problem that requires generics, mainly building 
things like the Ada containers.

> 3. Devices responsible to handle "registers" holding values;

I don't see how a generic would help here. It is illegal to have most 
representation clauses in a generic body, so I don't see how you could even 
have a generic in this case. (It certainly wouldn't work in Janus/Ada, can't 
talk about GNAT.)

> 4. Handles to registers;

Pretty much the same as the previous. The package involved would be so small 
and there would be so few of them (one for each kind of native register 
type) that I'd just copy the text and do a block substitution to make a new 
one. Generics would just get in the way (and add overhead on a compiler that 
does sharing, like Janus/Ada).

> 5. Publishing value change events and monitors of;

Maybe, if you need them to work on multiple types. Seems like a sort of 
container, to me.

> 6. Much whished, but practically impossible to do, bounded values.

Seems like that fits under #2 (it's not possible to do these without knowing 
the underlying representation, unless you're willing to make them very 
expensive with tons of barely necessary exception handlers). Here again, I'd 
make a package for each such type that I needed. (That's precisely how this 
issue is handled in the Janus/Ada compiler -- no generics in sight.)

 > Here you are. On top of that there exist immense problems with explicit
> conversions which needed between, say, a handle to a duplex register, when
> an output one is expected. It is not just N instances it is also 2**N
> combinations of cross operations.

Again, I don't see any good reason to try to separate these things.

>> Maybe you're trying too hard to be Object-Oriented;
>
> I am trying to have it type-safe. It would be just impossible to do in Ada
> 95. In Ada 2005, which has Java interfaces, it gives what I described. 
> Lack
> of MI, which is worked around using generics. I guess that MI would slash
> the amount of code by ten. MD would do another tenth.

It's not worth it to be type-safe in this way. Especially as 
preconditions/postconditions combined with static analysis give the same 
effect (compile time checking) with 10% of the work. There definitely is 
such a thing as being too type-safe. Of course, YMMV.

                                                      Randy.