[log in to unmask] wrote:
...
> If the parametric entity is a "library" entity for which numerous
> instances have been created, and one makes a minor change in it, say to
> increase the performance by a few percent, one may want to recompile
> only the instance relevant to a particular program -- say one where that
> procedure is in
> the inner loop.  If the program building system uses "eager evaluation"
> it might well decide to recompile all of the instances that ever existed,
> which could cascade throughout an extensive library.  It may compile
> instances that are not used in any program that is still in use.  The
> compile time is, however, secondary to the recertification time.  Some
> organizations have a not unreasonable policy that if something is
> recompiled, it has to be recertified before it can be redeployed.

Control over library contents is traditionally an extra-linguistic
activity.  You're complaining that some implementations may
provide insufficient such controls for your needs.  And you're
placing the burden of correcting that perceived flaw on the language
(and *all* its users).  That's inappropriate in both respects.  The
"program building system" is what?  The loader (linker)?  The
'make' utility?  The tool that maintains procedure libraries?  Surely
it doesn't consist solely of the compiler?  In any case, the language
specification is not suited to the purpose you intend.  Even with
all your explicit instantiation syntax, an aggressive "program
building system" may still aggressively "anticipate" your intentions
and do lots of those things anyway - *and* maintain all your old
versions as well on the assumption that you might still want to use
them.

> In addition to the obvious reason not to want separate instances of
> a parametric entity, there are good reasons for users to want separate
> instances of it.  For example, it may have a saved variable.  It is
> therefore desirable for users to be able to control whether separate
> but essentially identical instances exist.  I've never heard anybody
> whine about the burden of explicit instantiation in Ada.

Yeah, most people that don't like Ada simply don't use it.  A majority
of programmers, I'm lead to believe.  Few people complain about the
details of languages that they don't use.  However, this *was* one of
my first observations about Ada (in the early 80's): the declarations
were verbose and seemed to be unnecessary.  Whether making that
observation is to be called a "whine" is a distinction I'll leave to
others - along with all ad-hominem attacks.

This early in the process we should be concerned with the semantics
of the feature, and how to provide that most *legibly*!  Although the
issue of whether the feature is actually implementable is relevant,
obscure and (usually) uninteresting internal details of such implementations
are not.  If it is (much) later determined that explicit control is needed over
which instances are made available and when, and *if* it is determined
that the appropriate place for such controls is in the language, only then
will it be desirable to worry about such declarations in the code.

The declaration of an instance consists of associating a generic name
with  an explicit type signature.  That can be accomplished *much* more
legibly that you presently propose - I'm sure of it.  Among other problems,
you place the instance declarations in the context of references to the
procedure rather than where the procedure is declared, and you make
them mandatory.  Given your concern about certification, placement
of the instance declarations with the procedure's declaration and making
such declarations optional seems more appropriate - assuming that's
really the reason that you want the instancing control.  The point is that
legibility can only be enhanced if you clearly identify *why* you want
a given kind of control and then analyze how to best provide it.  Just
arbitrarily throwing in a syntax requirement that you *think* meets
your needs isn't good planning.  And it's likely to irritate the rest of
the users that don't need that particular control.

--
J. Giles