Re: Rational for not making cursor tagged in Containers

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

On Sat, 21 Apr 2007 23:28:34 -0500, Randy Brukardt wrote:

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

So how are you going to check the discriminant once, provided that the
value shall determine the validity? My point is that there are two values
of different types we are talking about, one with and another without the
discriminant.

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

Where is any problem? If the discriminant is statically determinable I can
reconstruct it at the call point, create a dynamically constrained object
[which is not necessarily contiguous in the memory] and pass it. If the
discriminant is indeterminable, then I must already have a dynamically
constrained object to pass.

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

No, that depends on the type of "ABC". What is "ABC"'First? There is no
logical way to derive it from the value otherwise than voluntarily set it
at some arbitrary value, like 1.

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

Neither I can do it with the latter. There is an operation which extracts
bits from the value. This operation has the parameter of some other type
and the result of third. I could define such operation on the former or
disallow it on the latter making the type private. Would that change its
elementariness? Just per view? Wouldn't F'Exponent make F non-elementary?
What about Boolean xor? May I claim that xor extracts a component of its
first Boolean argument in some Platonic universe? It just makes no sense to
me.

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

Yes, I meant that nothing would change for the types which presently have
no discriminants, if we allowed but not used them.

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

'Class is a difficult case. And a general question regarding it is, should
it be possible to have it "hyper-dispatching"? [sorry, for inventing new
terms on the fly]? I mean T'Class'Class. If yes, then we will have
different levels of tags. Another question is whether
"multiple-polymorphic" things were allowed. Here I mean multiple of tags at
the same level: T'Class(1), T'Class(2) etc.

I think these questions have to be answered in order to build a sane OO
types system. What I do believe is that this system could be uniformly
expressed in terms discriminants and impose no *any* penalty on computing
with specific types.

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

Yes, T'Class always has the tag (which is not necessarily dynamic).
 
>>>> 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...

It is not obvious to me. I guess that "type X is new Y with private" is
where it should stop. Certainly, I don't want to try to express the types
constraints in formal generic parameters. It would be a Sisyphean task
worth of nothing.

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

Certainly, but I guess that shared generic bodies have to "dispatch" to the
actual "with procedure" as well. In the end it should turn equivalent,
because, there is no implicit re-dispatch in Ada.

If the class-wide bodies are inlined, then in comparable cases the tags
will be known and all dispatching calls within them will be resolved
statically. The rest would be space overhead for storing tags. Now, if the
callee are inlined as well and type involved is not by-reference, then the
compiler can remove call T -> T'Class -> T conversions, it would otherwise
generate. That would mean no any overhead.

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