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

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.

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. Perhaps
the array syntax would have to remain, but it would just be a language
defined synonym for a record access.

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

                                           Randy.