Re: Rational for not making cursor tagged in Containers

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

On Fri, 20 Apr 2007 15:11:53 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1q1kx2jlcvnuj.ck0711mj4few$.dlg@40tude.net...
> ...
>> Also I fail to understand why polymorphic objects has to be records
>> and not arrays or access types. Why array or number cannot have
>> discriminants, but records can?
> 
> This ones easy. There is a fundamental difference between elementary types
> (which can represent only one value) and composite types (which can contain
> multiple values). Adding discriminants to an elementary type would turn it
> into a composite type -- and that way lies madness.

That's because you consider discriminant as a component. But why?
Discriminant is a constraint / parameter of a value. It is associated with
the value but is not necessarily a part of it.

Examples of discriminated scalar types:

1. type Ring_Buffer_Index (Size : Positive) is mod Size;

2. type Bounded_Integer (Min : Integer; Max : Integer) is range Min..Max;

3. type Dimensioned (Dimension : Unit) is digits 8 range -100.0..100.0;

4. type C_String (Length : Positive) is
       access all Interfaces.C.chars_array (1..Length);

Note the target is a flat array!

5. type Checked_Access (Not_Null : Boolean) is
       access not null (Not_Null) of Something;

The syntax is ugly, but I hope you got the idea.

> As far as why a polymorphic object has to be a record, that's simply because
> it is the most general composite type. It is a heterogeneous container.
> Indeed, I don't think I've ever implemented an abstraction as anything else
> (at least not for long); there is always a need for additional items beyond
> the main data.

Counter examples:

1. polymorphic access types (for smart pointers, interators, cursors) 

2, extensible enumeration types

3. polymorphic numeric types (mixed arithmetic implementations,
computations with mixed numeric representations)

> The better question is why there are arrays at all. A homogeneous container
> is by definition more limited than a heterogeneous one. So, the ideal
> language would find a way to completely unify arrays and records.

Yes, but first one should do something about static expressions. There is
no way to enforce keys of a record container to evaluate at compile-time.

> I suppose you could try to do something similar for elementary types (you
> can use special syntax if there is only one component in the container), but
> that would necessarily make programs fragile (adding a component would
> necessarily disallow that syntax, requiring massive changes).
> 
> So, I guess the ideal language would be one in which everything was a
> controlled record type. (For Janus/Ada, that's already true in many cases: a
> protected type is just a special controlled record type; task objects are
> essentially controlled, unconstrained arrays are really records that contain
> bounds and a data pointer, etc.) But such a language would be pretty
> space-inefficient (you could optimize individual calls to avoid dispatching,
> but there is no way to eliminate the space overhead, because you can never
> tell what might be done in some separately compiled unit.)

This is a consequence of IMO a wrong view on what discriminant (or tag) is.
If you consider them as components, you indeed land in the pitfall you
described above. But if discriminant is just an attribute of a value
forcibly removed when known static, then there is no any space loss. The
values of statically constrained / specific types will have no
discriminants / tags. Dynamically constrained / polymorphic values will
have it, just as dynamically constrained strings have a dope. Only the
[by-reference] types with the reserved words tagged or limited will have
discriminants and the tag among them stored the value. I think it is a
doable program.

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