🚀 go-pugleaf

In article <51097@tut.cis.ohio-state.edu> weide@elephant.cis.ohio-state.edu (Bruce Weide) writes:

   If there is to be a "reusable components" cottage industry, probably
   many components will only be available as specifications plus runnable
   code in object form.  This suggests that source-level optimizations
   that cross package/module boundaries may be of relatively little use.

Several of the systems which would support component distribution
easily also allow for "intermediate forms" of the code.  It doesn't
need to be a straight "source/object" distinction; you can distribute
the intermediate code.  For instance, a TeleSoft (<--prob. tm) Ada
library contains information which can be used for global optimization.

   What, then, can be done about the (apparent) inefficiency of reusable
   components?  The above argument suggests we should concentrate on
   designing abstract reusable components which at least permit efficient
   implementations, and then try to build very efficient realizations of
   these abstract components.  Performance trade-offs among different
   operations of the same component are inevitable, so we'll need to
   allow multiple implementations of the same abstraction to give the
   client programmer a choice of performance alternatives.

I agree.  It would be nice to have some sort of routine hierarchy,
which is typically handled transparently by the environment, but where
the programmer can override it.
  I would love to be able to say "sort(x)" and let the environment do
the work about figuring out how to do it (assuming that X is of some
type it knows how to sort...arrays of records, perhaps, if I've
defined a record-comparison routine).  I could then use
"sort.insertion(X)" if I decided that an insertion sort would give the
best performance in a particular implementation.  (Actually, I'd
prefer specializing it without the source code changing.)
  Yes, this would be work, but I think it might be a goal worth aiming
for.

							    And perhaps
   we should concentrate on, say, advances in run-time system design and
   in architectures so that genericity and the like do not introduce
   additional run-time overheads and so procedure calls are much faster.

True...though having a decent global optimizer, *** with inlining ***,
takes care of most of the genericity arguments I've seen.  (Of course,
the code size gets much bigger once you start inlining.)

   These might be more productive approaches for the long term than ever
   more complex compiler tricks whose effectiveness would be thwarted if
   reusability actually became a reality.

Might be.  I'm not sure about what you can do in architectures,
though.  I think developing a good environment which can give "hints"
to the compiler/linker might help....

+---------------------------+------------------------+
| Anton Rang (grad student) | "VMS Forever!"         |
| Michigan State University | rang@cpswh.cps.msu.edu |
+---------------------------+------------------------+