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.141711.20648@arnor.uucp>
Date: 10 Oct 90 14:17:11 GMT
References: <64618@lanl.gov) <2883@igloo.scum.com) <2171@enea.se> <1990Oct8.135551.21639@arnor.uucp> <14972@cbmvax.commodore.com>
Sender: news@arnor.uucp (NNTP News Poster)
Reply-To: lowry@lusitania.watson.ibm.com (Andy Lowry)
Organization: IBM T. J. Watson Research Center
Lines: 96

In article <14972@cbmvax.commodore.com>, skrenta@cbmvax.commodore.com (Rich Skrenta) writes:
|> In article <1990Oct8.135551.21639@arnor.uucp> lowry@lusitania.watson.ibm.com (Andy Lowry) writes:
|> 
|> >The Hermes programmer has NO notion of pointer in any of
|> >its various guises.  There is NO way for the programmer to specify
|> >aliasing or shared data of any kind.  We provide high-level data types
|> >called "tables" that subsume most of the uses that pointers are
|> >traditionally put to (linked data structures, character strings and
|> >other arrays).
|> 
|> Sure, if Hermes gives me my tree, linked list and array, I probably won't
|> need pointers as much as I do in C--the data structures have already been
|> implemented for me.
|> 
|> However, if I want to make something that isn't directly supported by the
|> language, I'll have to use my integer array index "pointers" to do it.
|> Can Hermes stop me from doing that?
|> 
|> Rich
|> -- 
|> Rich Skrenta
|> skrenta@cbmvax.commodore.com
The view in Hermes is that the programmer should not be concerned with
how data values are laid out in memory.  Hermes does not give the
programmer direct access to "tree, linked list and array."  Instead,
there is a very simple high-level data type called "table," with which
one can describe homogeneous collections of data.  The most basic
table type definition is:

	t: table of x {full};

where X is any other datatype.  This says that a value of type T is a
collection of values of type X, each of which is fully initialized
(this relates to another unique feature in Hermes called "typestate"
that I won't go into here).  If you want to operate on a specific
element of the table, you can do so with statements like:

	a := x in t where (x.color = 'red' and x.weight > 10000);

To iterate over a subtable you do something like:

	for x in t where (x.color <> 'blue') inspect
	begin
	  ...
	end for;

There are other statements for inserting and removing elements,
merging tables, and extracting or copying out subtables.

If, in your collection of data, position is important, then you add
the "ordered" keyword to your table definition:

	t: ordered table of x {full};

Then you can do things like:

	pos := position of x in t where (x.name = 'xyzzy');
	a := t[pos];
	a := x in t where (position of x = pos);

(The latter two are two different syntaxes for precisely the same
statement.)

If your table has keys in the relational sense (meaning all elements
must be unique with respect to each key), you can specify them:

	t: ordered table of x {full} keys (id) (a,b);

This would describe a table in which no two elements can have the same
id, or the same combination of a and b values.

The above is EVERYTHING you need to know about tables as a Hermes
programmer.  The compiler and run-time decide data representations and
algorithms for accessing your data.

Asking what Hermes would do if you wanted to implement a data
structure that we don't support misses the point.  With Hermes, data
representations are implementation details that the programmer need
not be concerned with.  Instead, the programmer is left to express
programs at a higher level of abstraction, where programming is easier
and less error-prone.

Of course, our language support does not allow all possible
relationships among elements of tables or among fields of an element
to be captured, but we're working on that (with user-defined
constraints verified and maintained via our typestate mechanism).

I should also mention that we have a notion of "pragmas" supplied by
the programmer that very well may take the form of *suggestions* for
data representations.  Pragmas, however, in no way change the
semantics of programs, and the compiler and run-time system are never
required to adhere to them.  We have done very little in the way of
defining and supporting pragmas to date.
-- 
Andy Lowry, lowry@ibm.com, (914) 784-7925
IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY  10598