Re: Sather: templates necessary?

[Eray Ozkural]

Norbert Nemec wrote:
> 
> 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.)

I think that depends on how you represent the program. The idea is
that anyway, you should be able to generate code just as much is needed.
Not assembly.

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

You're making some wrong assumptions. The compiler knows what types
are known and what types are parametrized at compilation-time.
Consequently, it can detect all errors which are indep. from what
parametrized types will take as value. [And there're ways to have
compile time assertions about types as I said]

That's why writing a "real" C++ compiler is a hard thing; not
something an average hacker can handle ;> I've thought about it long
and deep and found out that "avoid implementing C++" a nice decision.
Babbling I know, but writing a compiler for genericity is a very
delicate subject.

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

You can do it. I've thought about it, too. The problem is that you
won't be able to achieve many important optimizations once you go
that way. If you're just calling some stubs, then you sure won't
be able to take advantage of what exactly the parametrized type is.
It will have to be handled in a generic way, thus losing efficiency.
If you OTOH work with a flex intermediate code, you can just do a
unificiation and run the optimizer over intermediate code.

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

I don't think so. That's not a problem specific to C++. I don't see
how it is different than in Ada for instance. It's just the syntax
that differs, semantics is very close.

Note that in a right C++ template implementation, the template's
interface and implementation _are_ separate. template implementation
remains in a .h++ file and the implementation in a .c++ file! That's how
it should be, don't be deceived by the fact that *both implementation
and interface* of a template has to be included by cpp nowadays.

So, you don't need to access the whole internal code of a template in
order to compile a program using it. _Not The Source Code_ . The
code you will have to access is only the _partially compiled_
*program representation*.

As I said though there doesn't seem to be any compiler group that
has been able to apply this scheme. Maybe the IBM's C++ compiler
may, but I'm not sure at all.

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

The emulation I saw was pretty, but for other things the extra coding
that you do will be overkill (emulating a compiler is a bad thing).
For instance, I implemented a quite general version of expression
templates technique, and what I had was a very slow compilation time
and almost un-maintainable code.

[multiple polymorphism]

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

Same as in C++ or Java.


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

There may be some efficient ways to do it though. The thing is you
know how many dispatches you're going to handle! So if you have a
really cool compiler, you can get the compiler to work on just
that many dimensions. Making it faster than any emulation of multiple
dispatch! I'm not suggesting that sather should adopt it but there
is an intriguing relationship between generic code and mult. polymorphism.

cu,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: address@hidden
www: http://www.cs.bilkent.edu.tr/~erayo