Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.misc Subject: Re: C's sins of commission Message-ID: Date: 13 Oct 90 11:48:04 GMT References: <64618@lanl.gov) <2883@igloo.scum.com) <2171@enea.se> <1990Oct8.135551.21639@arnor.uucp> <11429@spool.cs.wisc.edu> <1990Oct10.143103.21001@arnor.uucp> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 55 Nntp-Posting-Host: odin In-reply-to: lowry@arnor.uucp's message of 10 Oct 90 14:31:03 GMT 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