Re: User-defined type attributes (replacing genericity)

["Randy Brukardt" <randy@rrsoftware.com>]

"Eric Hughes" <eric.eh9@gmail.com> wrote in message
news:821256cd-2d20-46dd-92d2-cdd21181dbb8@s8g2000prg.googlegroups.com...
> On Mar 14, 8:48 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> > Why there have to be two? The whole idea of generics was to have *one*
> > generic body. This is why it is called generic [programming].
>
> Here's the nut of the problem.  There is one generic body in the code
> of the programming language.  When you substitute type parameters into
> that generic body, you get multiple different manifestations of that
> original generic body, that is, multiple bodies, one for each type.
> And that means multiple versions as translated into machine code.

That has nothing whatsoever to do with Ada. Most Ada implementations work
that way, but there is no requirement that they do. Indeed, there are a lot
of rules in Ada specifically to allow the sharing of generic bodies. A
number of Ada 83 compilers used to do it as a matter of course; Janus/Ada is
the only one that I know that still does for Ada 95 and later.

This sort of performance is best handled by inlining, IMHO. It's virtually
impossible to share something that is generated separately (I know, I did
that extensively to shoehorn our compilers onto Z80s back in the dark ages);
it's a lot easier to "unshare" something that is shared than the reverse.

Janus/Ada was designed around this plan; unfortunately, circumstances (and
the underpowered machines of the late 1980's and early 1990's) meant that
the inlining linker never got built. It actually wouldn't be all that much
work (I think a couple of man-months), but it is still too much to tackle at
the moment.

> A realistic system for generic programming should support both modes
> of code generation.  This allows the developer to determine their own
> answer to the code-size vs. performance trade-off.

Actually, much of the time the compiler has a pretty good idea. All it needs
are some hints.

This is one thing that Java compilers have over Ada ones, because the Java
program usually already has been running a while before it is compiled, so
the areas that need to be concentrated on for speed are known.

In any case, 95% of programs are fast enough without any fancy optimization.
And 4% of the rest don't need much. Most people spend way too much time
worrying about the last 1% (probably because it is more interesting than
getting work done -- just like answering your note is. ;-)

> Ada has already taken the stance, as evidenced by representation clauses,
> that it will support both high and low levels of abstraction.  Eliminating
generics
> would force everything into virtual function calls, choose code-size
> over performance, and make that choice on behalf of every programmer.

Yup, and that probably would be the right choice most of the time. Moreover,
there is no problem using static binding, partial evaluation, and inlining
to get rid of the majority of the virtual overhead. Remember, Ada statically
binds calls to tagged types; it's pretty hard to write dispatching calls.

(I know of a number of bugs in that area in Janus/Ada, yet no one has yet
written a program that has hit any of them. Or at least they've never
reported them. Obviously, they're not that high of a priority to get
fixed...)

> If you go down the road of requiring all method calls to be virtual,
> of requiring that there be run-time manifestations of all meta-
> language features, you get Java.  Java has its place.  So does Ada.
> These aren't the same place.

How you compile makes all the difference. The language doesn't make that
much (it does make some), as long as there is reasonably strong typing so
that calls can be statically bound. But I realize few people agree with me
on this; had we actually been able to build the entire compiler system that
we had envisioned (with C and Ada front-ends, and three backends: checkout
interpreter, conventional fast compiler, and highly optimizing link-time
compiler) I suspect that either a lot more people would agree or no one
(including me) would.

                               Randy.