Re: User-defined type attributes (replacing genericity)

[Georg Bauhaus <rm.plus-bug.tsoh@maps.futureapps.de>]

On Fri, 2008-03-14 at 15:48 +0100, Dmitry A. Kazakov wrote:

> > I assume your answer to what follows will be that Ada semantics
> > should be put under programmer control,
> 
> What's wrong with having control over the semantics?

(Control over the semantics of the language. I'm not a compiler,
and I'm not imagining I am as good as someone who can routinely
master the advanced parts of implementing Ada in user programs.
That is what I think will be wrong.

It is certainly possible to imagine some meta-flavoring for
Ada. But I don't want to inspect such pieces of sophistication
when they come out of the hands of ordinary programmers
and have errors. There will be at least one more
level of linguistic indirection between me and the LRM:
the programmer's language interpretation as implemented in
his semantics control.)


> No, what you need is an interface implemented by both. You need to declare
> Simple implementing Ordered. That will tell the compiler that the
> predefined "<=" is an implementation of Ordered's "<=".

Actually, it doesn't matter whether "<=" is predefined. It could
just as well have been a user defined "<=". The Foo(...'Class) would
have had one one general ("generic"?) implementation of Is_Highest,
as described. This Is_Highest will have no specialization, but
it will feature highly stylized indirection, dispatching to the
implementing code for the respective "<=".


> > Without generics, there is only one Is_Highest, as might be
> > expected. 
> 
> 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].

I *can* have and I *did* have just one body in *source* code.
We both know that Ada does not anywhere require that generics
must not yield more than one lists of object code per
generic. This would seem like a stupid restriction, one that
I think no one has wanted to put in the minds of the language
makers.


> If you want to constrain the dispatching table
> to the diagonal

I don't want that language to inflict a dispatching table
on me when that offers no advantage at all!

- I don't need any dispatching here,
- My code is more efficient without it,
- Review of the generated code is simpler because
  there are fewer indirections.
- There still is abstraction.

If that doesn't count as advantages ...


>  Do not sell a limitation of generics to a
> certain type of constraint as genuine advantage.

>From looking at generated code, the genuine advantage seems
to be the total absence of dispatching code.
Absence of code whose major contribution can, by the impression
of the assembly listing, roughly be expressed as

 X.all.Call_Maker.all.Invoke

instead of

 X.all.Call

in the generic case