Re: Rational for not making cursor tagged in Containers

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

On Mon, 23 Apr 2007 18:26:39 -0500, Randy Brukardt wrote:

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

I have to. The same problem exists with the strings, when a string object
is renamed to an object of a string subtype with different bounds. The
compiler silently ignores new bounds. This is *wrong* and it has to be
changed. The rule should be: a constraint once set on a subtype cannot be
changed without construction of a semantically new value.

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

Yes, of course. Values do not exist in the program. You are right, I should
have used "object" instead of "value."

Still bounds is not necessary in the string value, which is an ordered set
of characters. You can enumerate that set in any way.

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

The point is that there is no way to define elementariness otherwise than
in terms of operations defined on the type. So in a language with ADTs,
where operations can be defined and disallowed, elementariness has no any
meaning other than, say, no function "." (X : T) return * is invisible in
the current context. Why should visibility of "." or "()" have any effect
on discriminants?

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

Somebody who would try it. (:-))

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

Yes, this is the price to pay for sharing the bodies.

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

Another possibility could be lazy expressions, so that class-wide value
will be constructed in the body later, probably never when the tag is used
solely for dispatch. But passing closures might be even more expensive.

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

Actually, I wished to add some "clues." Otherwise, I agree, it would not
work. It should not become another question of optimization. It should be
possible to explicitly state that the constrained subtypes of the given
type have no stored discriminants. Further there should be a way to tell
that all discriminant expressions of static arguments to be evaluated at
compile time.

In my view it is more serious problem that allowing discriminants
everywhere. Because I see no obvious way to convert a "Constraint_Exception
might be raised at run-time" into "this program is illegal."

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

I think that it would not be worth any efforts in that case. The goal
should be a much simpler language with much less classes of types and
special cases. What I want is that record, array and T'Class became
user-defined things.

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

That is not the goal. For the start it would be good enough just to get rid
of generics...

Also the programming techniques and patterns customary used in class-wide
programming are quite different from ones used with generics. One cannot
foresee the effect of the shift. One should really try and see.

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