Re: Rational for not making cursor tagged in Containers



"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:15dj4pbkifj9c$.1g4y21vyx4j4d$.dlg@xxxxxxxxxxxxx
On Sat, 21 Apr 2007 00:33:12 -0500, Randy Brukardt wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> 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.


.



Relevant Pages

  • Re: Rational for not making cursor tagged in Containers
    ... Adding discriminants to an elementary type would turn it ... Discriminant is a constraint / parameter of a value. ... If Ring_Buffer_Index can be used as an array ... All constrained access types are madness. ...
    (comp.lang.ada)
  • Re: Rational for not making cursor tagged in Containers
    ... Discriminant is a constraint / parameter of a value. ... access discriminants of task types. ... Here I mean multiple of tags ... If you do shared generics as we do, ...
    (comp.lang.ada)
  • Re: numbers as generics parameters
    ... Note also that the constraint to have equal strings is only an example ... type Pascal_String is new String; ... the subtype is a proper constraint. ... why generics are not a ...
    (comp.lang.ada)
  • Re: User-defined type attributes
    ... The syntax for invoking an attribute may imply a dynamic function ... Ada's generics lack ... discriminants with it. ... does not hold since Ada 95, ...
    (comp.lang.ada)
  • Re: can constraint generics using string or not ?
    ... a non-sealed class or a type parameter ... Why can't I constraint using string but I can constraint like bellow and ... Since this is not a valid use of generics, possibly you are trying to solve a problem for which there is a better way than generics. ...
    (microsoft.public.dotnet.languages.csharp)