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:15dj4pbkifj9c$.1g4y21vyx4j4d$.dlg@40tude.net...
> On Sat, 21 Apr 2007 00:33:12 -0500, Randy Brukardt wrote:
>
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
...
> >> 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.
>
> Sure, example: access discriminants of task types.

Huh? Two tasks never have the same value.

> It is not madness, it is the same difference like between class-wide and
> specific. These are different though mutually compatible [sub]types. A
> dynamically constrained value has discriminants, a statically constrained
> value does not have the discriminants whose values are statically known.
> Even if these are still kept in the value bit pattern. Known discriminants
> are undeterminable from constrained values [for sanity reasons].

Huh again? You have to know the discriminants, or you couldn't pass them to
an unconstrained (or, if you prefer, 'Class) parameter.

> > 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.
>
> The values are not same, String is not String (1..80).

String is a type, not a value. String(1..80) is a subtype, not value. "ABC"
is a value and that value includes its bounds.

...
> Hmm, what is the difference between elementary and non-elementary? In
which
> way mod 256 is more elementary than array (Positive range 1..8) of
Boolean?

One is a single value, the other is a set of values. You can do math on the
former to extract bits, but you can't get at them directly.

Surely, you could design a language with only kind of type (a super-record).
But it would be highly inefficient; there'd be a few special cases that
could be fast, but they wouldn't happen that much.

> To me the only difference is built-in vs. user-defined, which vanishes in
> absence of visibility on the private declarations.
...
> > ...
> >>> 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).
>
> Because presently discriminants are not allowed, so, I presume, they are
> all static. I.e. it definitely works! (:-))

Discriminants are not allowed where? I was talking about where they are
allowed; if you extend them to be allowed everywhere. Of course, a compiler
could special case no possible discriminants (I think it would have to,
adding a complexity). But if you allow adding them to extensions (and it
seems you should), then not 'Class ever is known to not have discriminants.
So they're almost always dynamic, and they have to almost always be part of
the value. (And there are a lot more uses of 'Class in your universe without
generics!)

> > 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).
>
> Just 2500? (:-))

Parameter passing is one of the easiest (conceptually) things that a
compiler has to do. It's just evaluate and push. For that to get that
complex is outrageous. (Yes, our shared generics are a major culprit.)

> >> 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
>
> If no new formal generic types will be introduced, then I don't see it as
a
> big deal. Possibly generics will never be get right, but that is not
> because of discriminants. (:-))

If you do shared generics as we do, generics essentially double the work for
everything. You idea would multiply it by 4 again. I think that's beyond my
ability to imagine...

...
> > 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.
>
> Generics is a sufficiently different thing. The constraint is put on the
> compilation unit like package and then it propagates to the declarations
of
> the unit. The closest approximation is derivation, which puts tag
> constraint on a class-wide. It would be interesting to analyse some
> large-scale Ada code. I guess that less than 10% of all calls with tagged
> arguments would be dispatching. I.e. 90% is static.

It might even be less than that. But I was referring to your previous
comments on how lousy generics are in a general way. I was presuming that
your ideal language would not have them. But then you'd have to have a lot
of operations on 'Class (to get a polymorphic Put, for one example). In
which case there would be far more dispatching calls than in Ada (we tend to
use generics rather than inheritance, I think).

                              Randy.