Re: Rational for not making cursor tagged in Containers

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:desawg9du795$.1nlp3h75ktl4a.dlg@40tude.net...
> 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.

That way lies madness. You could have the same value yet they wouldn't pass
the checks because this stuff that isn't part of the value doesn't match.
That's very different than a range constraint, for instance, which is
outside the value, but it doesn't change the checking of the value. That is,
values don't have constraints.

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

These would be possible in Ada (as records) if there wasn't a rule
specifically forbidding it. And the reason for the rule is simply that there
isn't any real value to these sorts of constructs. even if there was,
though, mapping them as records, assuming a decent way to handle literals.
No reason to treat them as elementary.

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

Same here.

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

All constrained access types are madness. It isn't possible to make any
useful meaning out of them, and they cause an infinite number of
definitional problems. Ada shouldn't have ever had them (we've essentially
made them illegal for general access types, but we can't do anything about
the Ada 83 ones).

In any case, *my* language would de-emphisize access types as much as
possible. No anonymous ones; probably structural matching (so the named ones
would work a lot like the anonymous ones of Ada); in out parameters serve
the purpose better anyway. They'd be second-class citizens to discourage
their use by anyone other than people implementing containers...

...
> Counter examples:
>
> 1. polymorphic access types (for smart pointers, interators, cursors)

No anything for access types; they should be made so hard to use that it's
almost unthinkable to do so. All of the things you mention are ADTs,
implemented by controlled records. (Dereference would also be a possible
redefinable record operation, of course.)

Yes, you'll occassionally need access types to implement ADTs, but never,
ever visibly in a spec.

> 2, extensible enumeration types

We tried to work this out, and it simply doesn't work. Operations like
ordering simply aren't extensible in a useful way.

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

Maybe, but I'm dubious. Again, I think it would be better to have better
ADTs that could replace a numeric type.

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

These are almost never known to be static (consider parameter passing). What
you're suggesting *might* be possible to describe, but it wouldn't be
possible to implement. If the parameter passing code in Janus/Ada got any
more complex, it could never be made to work (it might already be at that
point - there's over 2500 lines of code for that alone).

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

Maybe, but only if you're successful in getting rid of generics and most of
the other special cases (like "view conversions"). Otherwise, it is just too
complex to implement. And if you do get rid of generics, I think you'll find
that nothing significant is ever known to be static.

                               Randy.