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

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

On Mon, 24 May 2004 11:38:38 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

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

No, there is only one more level of indirection needed as compared to
single dispatch. Consider a procedure dispatching on three arguments:

procedure Foo (First : A; Second : B; Third : A);

It has the dispatching table:

Foo.Impl (i, j, i) -> Implementation

Then for each independent argument there is an index map:

Foo.A (A_Tag) -> i
Foo.B (B_Tag) -> j

So to disptach to Foo the compiler should resolve:

Foo.Impl (Foo.A (First'Tag), Foo.B (Second'Tag), Foo.A (Third'Tag))

All arrays here are dense.

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

An index type interface is more than just something ordered. What
about 'Pred, 'Succ, 'Range, copy constructor, default constructor etc?
[BTW, multi-dimensional indices are unordered, (1,2) > (2,1)?]

When you write in a generic interface something like "type X is <>",
you in fact specify an interface to be implemented. During
instantiation the actual type is checked against the interface. If
check is OK the implementation is accepted. One can do same for
non-generic interfaces. 

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

I see no technical reason why generic instantiations should be more
flexible in that respect. AFAIK ARG is going to relax some
restrictions anyway.

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

for I in A'Range loop
   A (I) := 0;
end loop;

Is it impossible to write

A(A'First) := 0;
A(A'First + 1) := 0;
A(A'First + 2) := 0;
A(A'First + 3) := 0;
...
?

>: 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?  ;)

I do not see how they could help. Consider a program (say parser) that
should work with both String and Unbounded_String. When the type is a
generic parameter, then the whole compiler will be generic too.

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

C++ has MI.

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de