Re: "Must instantiate controlled types at library level." Why?

[Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de>]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: Georg Bauhaus wrote:
 
: That's no problem. The type tag could be an index in a multidimensional
: dispatch table.
 
With fallback entries, so you don't have to provide entries for
all m x n x k for a function of (Tm, Tn) -> Tk, I guess, where
m, n, and k the number of types in the respective type trees?

:> If everything that some construct like abstract array indexing needs
:> has to be provided by the implmenting types, this might easily lead
:> to type inflation.
: 
: How it differs from what we have now: [...]
: You have to implement ">" before you instantiate.

You won't have to add a type with an implementation of a
comparison interface. All that is needed is a comparison function,
inheritance/implementation is not involved.

:> I'm not sure whether or not this is better than to
:> define operations based on what the type already has, and near where
:> they are needed.
: 
: You will have this for free with multiple inheritance.

Yes, but it restricts the number of locations where you are allowed
to implement the needed functionality, if you have to implement it.


:> How do you manage to write code so the compiler will know
:> it deals with numbers of the kind required in some algorithm
:> involving Array or MultiArray without whole program analysis?
: 
: You cannot have objects of an abstract type (interface). So what you would
: do to write a program dealing with all kind of numbers? Presently it is
: impossible, so there is nothing to compare with.

OK I was referring to algorithms that only need a certain kind
of number, like somthing that can be done using real numbers or
complex numbers.
Is it impossible to have a generic function that operates on
reals as well as on complex numbers?
 

: I have an idea of ad-hoc supertypes. Instead of making all numbers derived
: from Number, sharing its implementation, which will be either impossible or
: inefficient, we could create such supertypes as necessary *afterwards*. So
: if you want to bring Integer and Float under one roof, you create a common
: non-abstract supertype MyNumber. This would require an implementation for
: MyNumber, which can be made more efficient, because you know all the
: players.

What's wrong with generic units that work like this, with either formal
tagged types or explicit requirements listing with defaults?  ;)
(In Ada200Y you can even have multiple interfaces, IIRC.)

Maybe you want take Eiffel into account, as it has a lot of what you
seem to want, including full multiple inheritance?