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:1q5s2gqbzhatf$.2xu8gdz4hxm8$.dlg@40tude.net...
> 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.

I'm sorry, but I have no idea of what you are talking about at this point. I
think our discussion has gotten two abstract, and precisely what is being
proposed is no longer obvious...

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

You said "Known discriminants are undeterminable from constrained values
[for sanity reasons]." So where else do they come from? The type of the
value contains no information (they're always unconstrained); the subtype
can be changed trivially (so you can't depend on it).

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

No, I meant that a value is a set of components and bounds, "ABC" is
(almost) the closest thing that you can write. A literal is not a value,
either. There is no notation for a value! Every value has
bounds/discriminants; where they come from is part of the language
definition. Assuming them is just fine, or specifying them, or consulting an
oracle...

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

No, of course not. But we're not talking about user-defined operations,
we're talking about what is available by default.

> Just per view? Wouldn't F'Exponent make F non-elementary?

You're probably right; but of course Float types follow no sane model so I
don't care much about them. You can't design anything sensible if you worry
about them. Just bolt 'em on to whatever model you're using and continue.
;-)

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

You could argue anything, but doing so doesn't make it sensible.

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

OK. But your premise is not really true; the compiler complexity would jump
dramatically, and thus the number of bugs in the compiler would jump as
well. Similarly, the language definition would almost certainly be written
for types with discriminants; the rules for the no discriminant case would
no longer exist separately, and thus they would be subtly different.

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

Maybe. I'm not so sure. But in the absense of a real attempt to do so, who
can tell?

> > 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 original object's tag might not be dynamic, and might be possible to be
omitted (even if it is logically present). But once you pass it to T'Class,
you have to include the tag dynamically, because it can be anything. (Well,
unless you are engaging in full-program optimization. But that's not
practical in real systems today; anything added on the fly destroys
full-program optimization.)

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

Your scheme boils down to having a very general type system for which the
compiler recognizes and special cases any combination of things where it can
be done better (that is, discriminants can be omitted, tags can be omitted,
by-reference parameter passing should be turned to by-value, etc.) There
would be no syntaxtic "clues" as to when such optimizations could be done;
there could be nothing consistent about the representation of types. Very
little about how to build compilers as I know it could be used.

Perhaps, if you are starting with a completely blank page with really
brilliant people, it could be done more cheaply than I could. But then the
problems inherient in starting from scratch would occur: lots of bugs,
especially coming from places where the rules don't fit the design.

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

That's my point; it is farily equivalent. And there is essentially nothing
static in our generic bodies. I don't see how you could avoid that in a
"unified" language.

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

Very little can be practically inlined: either very short routines or
routines that are only called once (and the latter requires full-program
optimization, which is problematic as noted earlier). Anything else will
cause an explosion in code size. Thus, talking about what could happen when
something is inlined is irrelevant -- of course inlined code will be better
than non-inlined code, but the bulk of a program will not be inlined.

Similar, any *as if* optimizations are always fair game for a compiler, but
they're irrelevant when evaluating the semantics of the usual case. You
can't assume that optimizations are going happen - often they're only
applicable in trivial cases that rarely occur.

                           Randy.