Path: utzoo!attcan!uunet!bywater!arnor!lusitania!lowry
From: lowry@arnor.uucp
Newsgroups: comp.lang.misc
Subject: Re: C's sins of commission
Message-ID: <1990Oct10.143103.21001@arnor.uucp>
Date: 10 Oct 90 14:31:03 GMT
References: <64618@lanl.gov) <2883@igloo.scum.com) <2171@enea.se> <1990Oct8.135551.21639@arnor.uucp> <11429@spool.cs.wisc.edu>
Sender: news@arnor.uucp (NNTP News Poster)
Reply-To: lowry@lusitania.watson.ibm.com (Andy Lowry)
Organization: IBM T. J. Watson Research Center
Lines: 51

In article <11429@spool.cs.wisc.edu>, larus@primost.cs.wisc.edu (James Larus) writes:
|> In article <1990Oct8.135551.21639@arnor.uucp>, lowry@arnor.uucp writes:
|>   ... Long discussion of the abscence of pointers in the Hermes language...
|> |> 
|> |> Of course, our compiler and run-time system make heavy use of pointers
|> |> and shared data for reasons of efficiency, but this is completely
|> |> hidden from the Hermes programmer.
|> |> 
|> 
|> Does this mean that Hermes programmers aren't concerned with efficiency?

We believe that getting a program logically correct and making it
efficient should be two independent tasks.  The Hermes language allows
this separation by not requiring the programmer to make decisions that
will determine efficiency.  Data representation is just one example of
this.  Others are replication and migration of processes and/or data,
concurrent execution of programs written in serial form, etc.  It is
part of our continuing research to develop very aggressive and
high-level optimizations of this sort so that programs written in our
model will, in fact, execute efficiently in a wide range of
environments.

The programmer can also be involved in tuning, but this should
generally come only after the program has been made correct.  The
tuning comes in the form of sprinkling "pragmas" around the code in
various places.  None of the existing code is changed as this is done,
and the pragmas have absolutely no semantic effect on the program.  In
fact, the compiler and run-time system are allowed to completely
ignore the pragmas, though typically they would not.  Pragmas could
take a wide variety of approaches, like "You shoudl use a bit vector
to represent the following table of booleans", or "This table will
most often be accessed with queries of the following form:..." or "The
following section of code will insert many elements into this table
without otherwise referencing the table" (so perhaps a more efficient
off-line bulk insert algorithm can be chosen), etc.

The first sort of pragma would be a direct suggestion by the
programmer.  The other is behavioural information that can help the
compiler and run-time system make better choices.  The latter could
conceivably be generated by profiling tools, thereby making the tuning
process at least semi-automated and dynamic.

We have not yet addressed the pragma issue to any great extent.  In
particular, we have not made any decisions as to the form pragmas
should take, and our compiler does not pay attention to any pragmas.
Our first step, which we believe we have achieved, was to design a
powerful language in which correctness and efficiency could be
separated as we believe they should.
-- 
Andy Lowry, lowry@ibm.com, (914) 784-7925
IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY  10598