Re: Sather: templates necessary?

[Norbert Nemec]

On Wed, Oct 11, 2000 at 03:02:26AM +0300, Eray Ozkural wrote:
> Norbert Nemec wrote:
> > 
> > Be careful: 'templates' as known in C++ and 'parameterized classes' in
> > Sather are two distinct concepts: templates are something like a
> > cut'n'paste mechanism. A template really only becomes a meaning at
> > instantiation time. It is not "complete" before you tell the compiler
> > what it should use for the template parameters.
> 
> Err. no. Templates in C++ are not different from generic constructs
> in other languages essentially. The original cfront implementation
> did textual substitution to implement templates but that is just
> a matter of implementation. In current compilers, more intelligent
> strategies are employed to that end.

Explored, yes, but that will not be easy after how the specification 
defines Templates. Be aware, that the compiler has no idea even how 
large the type will be in memory. It may be possible in special cases, 
but in general, you will not be able to create code for a routine 
without hardcoding the kind of data it is handling. (Except you handle 
only raw pointers and do nothing with them.)

> > One of the results is
> > that, quite often, you get ton's of error messages once use first
> > instantiate a template, just because they could never be checked before
> > by the compiler.
> 
> Not that way for a long time, because compilers check templates
> for errors before they are instantiated.

How would you? Without instantiation, the compiler has no idea what it 
can do with the type it is handling. (p.e. is it possible to add the 
type? and: what is the result of such an addition etc.)

> > Parameterized classes on the other hand, could (if the compiler did
> > work properly, which ours probably does not at the moment) even be
> > compiled without being instantiated: Since every parameter of the class
> > is known to fit some abstract class ($OB if none is specified), every
> > occurrence could be just handled as a reference to a object of that
> > type. Therefore you could have a precompiled library containing code of
> > a parameterized class. Of course there is much optimization possible
> > once the the class is instantiated, but that's another matter.
> >
> 
> Correct. But in a true C++ implementation (which I believe does not
> really exist except perhaps IBM's C++ compilation system which had
> a few features I gasped at), the same thing should be done. The output
> of a generic library does not go into an object, but a generic object
> which is partially compiled and parametrized code. The compiler saturates
> the lacking parameters and proceeds with full code generation and
> optimization. The generic objects would probably be a dump of internal
> program representation (also called intermediate language :)

Sather would allow to do without any kind of intermediate code: 
Theoretically it would be possible to use a class if you only have the 
plain interface and a plain .o file. (Yes, I'm just about doing a 
little studies on that matter. It *is* possible.)

That's what's part of the problem in C++: You will always need to 
access the whole internal code of a template in order to compile a 
program using it. Maybe, that can be hidden in some "intermediate-code" 
file, but as soon as the implementation of the template changes, you 
will always need to recompile the programs using it.

> Abstract classes can even be implemented (approximately)
> in C++ with some ugly-looking tweaks. The GNU libstdc++ v3 has
> some IIRC.

Of course, you can emulate about everything in C++, but you will have a 
hard time get the compiler to check that for errors...

> > > Secondly, is multiple-polymorphism possible in Sather?
> > > Multi-methods?
> > 
> > What is it? Sounds strange to my ears, but it may well be, it is just
> > called differently or included in some larger concept.
> > 
> 
> multiple polymorphism is the generalization of polymorphism. A simple
> example would be (in pseudo code)
> 
>   Display d;
>   Shape s := new Rectangle;
>   Brush b := new Airbrush;
>   
>   ...
>   d.draw(s,b);  -- polymorphic on s and b, and not d!
> 
> Here is an example of a double-dispatch. A multiply polymorphic
> function call interface would allow polymorphism on any number of
> parameters not just "self"

In it's full extend, this is not, and never will be possible in Sather. 
But there are two things you can do: Either use overloading, that 
means, Display needs to know all the possible codes of drawing devices, 
and shapes and the resolving is done at compile time, or reverse do the 
dispatching the other way around internally, i.e. let all shapes and 
all drawing devices subtype from certain abstract classes that offer 
all that a display needs to know about them.

Realize, that for true multiple-polymorphism, you would in some way 
need a multi-dimensional dispatch table that has to be extended every 
time one class is added. That may be possible in a interpreted 
language, but in a compiled language it would become very ineffective.

Ciao,
Nobbi

-- 
-- ______________________________________________________
-- JESUS CHRIST IS LORD!
--          To Him, even that machine here has to obey...
--
-- _________________________________Norbert "Nobbi" Nemec
-- Hindenburgstr. 44  ...  D-91054 Erlangen  ...  Germany
-- eMail: <address@hidden>   Tel: +49-(0)-9131-204180