Survey, Larch/CLU, Higher-order operators

To: larch-interest@pa.dec.com
Subject: Survey, Larch/CLU, Higher-order operators
From: "Jeannette M. Wing" <wing@cs.cmu.edu>
Date: Tue, 10 Jan 95 10:52:57 EST
Delivery-Date: Tue, 10 Jan 95 08:00:56 -0800
In-Reply-To: Mitch Cherniack's message of Mon, 09 Jan 1995 18:41:23 -0500 <199501092341.SAA01237@trixie>
Sender: Jeannette Wing <wing@VOILA.VENARI.CS.CMU.EDU>


Dear Larch people,

1. Larch Survey

I put the results of my July 1994 survey of the larch-interest group
off my home page (via the Larch Project):

   http://www.cs.cmu.edu:8001/afs/cs/user/wing/www/home.html

It's not up-to-date but it may give some of the recent newcomers
a feel for the interests of the others on this list.

2. Larch/CLU

I don't think my MIT TR-299 (Ph.D. thesis) is available on-line.
In fact, I don't even know if it's still in print!  Best to ask
John Guttag (guttag@lcs.mit.edu).  Sorry to pass the buck, John.

3. Higher-order operators

In my Ph.D. thesis I discuss briefly the essence of the problem with
specifying higher-order procedures.  There is no problem if the
functional argument, F, is side-effect free since you can define a
trait function, t, that captures the relationship you want and then
you can just use t (the trait function) in the post-condition of your
interface specification.  (There remains the unsatisfying issue that
the post-condition does not insist that you actually call F but only
that you effect the behavior captured by t; but, that's a separate
issue.)  The real problem is when the functional argument has
side-effects.  If you use a trait function to capture the behavior,
then, in what states do you evaluate the predicate that involves this
trait function?

Notice that iterators are really a special case of higher-order
operators.  Both Mark Vandevoorde and I handle them for CLU in a
stylized way.  The extra mechanism needed gives you an idea of what
the problem is with higher-order operators in general.

Finally, Extended ML (an algebraic specification language that is a
superset of the FUNCTIONAL subset of the programming language ML) does
handle higher-order functions.  But, since it deals with only the
functional subset of ML, it doesn't have to worry about functional
arguments with side effects.  See Sannella and Tarlecki's work on EML.

There really hasn't been a very satisfying way of handling this
problem in general, especially in the Larch context.  This has been an
open problem for a long time.

Jeannette Wing

Follow-Up(s):

Re: Higher-order operators

From: leavens@cs.iastate.edu (Gary Leavens)

Reference(s):

New member of mailing-list

From: Mitch Cherniack <mfc@bullwinkle.cs.brown.edu>