🚀 go-pugleaf

On 10 Oct 90 14:31:03 GMT, lowry@arnor.uucp said:

lowry> We believe that getting a program logically correct and making it
lowry> efficient should be two independent tasks.  The Hermes language allows
lowry> this separation by not requiring the programmer to make decisions that
lowry> will determine efficiency.  Data representation is just one example of
lowry> this.  Others are replication and migration of processes and/or data,
lowry> concurrent execution of programs written in serial form, etc.

Well said. Note that under the idea that what we really want to do is
reuse of interface, semantics, implementation, you are saying that it is
efficient to achieve a lot of reuse of interface and semantics is by
having a very high level language. Agreeable point.

lowry> It is part of our continuing research to develop very aggressive
lowry> and high-level optimizations of this sort so that programs
lowry> written in our model will, in fact, execute efficiently in a wide
lowry> range of environments.

I most strongly object to call this 'aggressive optimization'. It makes
'aggressive optimization' look respectable.

Aggressive optimization is where the optimizer rewrites your program in
a supposedly similar form behind your back. In your case you are just
doing competent implementation of high level constructs, which were
carefully designed with clean semantics to give ample opportunities for
safe application of sophisticated implementation strategies.

The query planner of a relational database does not do any aggressive
optimization -- it is just required to do its job well. It starts to be
aggressive if it rewrites queries before planning them, and hen it
becomes really obnoxious only if the algebra underlying the query
language is poorly designed, like in SQL. But note that in a well designed
high level application language there *should* be no point in
restructuring a user's program, even in the presence of a clearly
defined and safe algebra for doing so -- there is essentially only one
canonical form of achieving an effect.

lowry> The programmer can also be involved in tuning, but this should
lowry> generally come only after the program has been made correct.  The
lowry> tuning comes in the form of sprinkling "pragmas" around the code in
lowry> various places.

Well said. 'register' or 'inline' come to mind immediately, at a much
lower level of abstractions, or providing expected domain value
statistics and join paths to a query planner or relation creator for a
relation database.

Again, of course, as far as current technology is concerned, we are
speaking of *application level* programming. Somebody has still got to
do the bit twiddling.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk