RE: succinctness = power

[address@hidden]

Dan,

What you list are "contracts" not types. They are properties of the code
that should (1) be stated and (2) in many cases be montiored at run-time.
When they fail to hold up, the monitor should infer/know whom to blame.

The list has discussed this issue before. There are a number of levels of
contracts that one needs:
 syntactic (eg, types)
 functional (eg, assertions a la Eiffel)
 sequencing/concurrency (eg, call f before you call g)
 quality of service (eg, ensure that this code serves at least 50
requests/min)

Eiffel has this notion of "design by contract." It is broken, in principle,
but
Eiffel programmers swear by it (english?).

Robby Findler has just finished a thesis studying the functional level. He
added
a bunch of ideas to the OO and higher-order  functional world. He will
continue to
look at this issue. He also studied "functionally dependent contracts".

There is also a recent dissertation out of Karlsruhe that looks at
"dependent contract"
or "adaptible" contracts. Unfortunately the thesis is written in German. If
you know
German and you're interested, I'll send out a reference.

In general, I agree with you that this topic is overdue for serious
research. Programmers
should be able to write such semantically deep contracts so that their
"psychopathic"
successors (see my Web page) can read and study such code.


-- Matthias


> -----Original Message-----
> From: owner-ll1-discuss@ai.mit.edu
> [mailto:owner-ll1-discuss@ai.mit.edu]On Behalf Of Dan Weinreb
> Sent: Friday, May 31, 2002 2:19 PM
> To: kanderson@bbn.com
> Cc: jeremy@zope.com; pg@archub.org; ll1-discuss@ai.mit.edu
> Subject: Re: succinctness = power
>
>
>    Date: Fri, 31 May 2002 11:12:12 -0400
>    From: Ken Anderson <kanderson@bbn.com>
>
>    Kent Beck says that no more than 1% of the lines of code he writes is
>    documentation.  He does work hard at making the code he writes clear.
>
> Unfortunately, I find there are often things that I, as the writer,
> want to express to the (future) reader of the code, which are not
> sayable in the programming language.
>
> Here are a few from our code base:
>
>
>     // NOTE: For each call to SomeFactory.init() in this method,
> there must
>     // be a corresponding call to SomeFactory.destroy() in
>     // Node.destroyAll(). Factories must be destroyed in reverse of the
>     // order they were initialized.
>
>
>
>     } else {
>       // Send a message to the PFE that does handle this PRN.
>       // It is important that the resume happens in the right
> PFE, since timers
>       // only work if they are started and stopped by the right
> PRN for the
>       // instance.
>       sendSignalToProcess(pid, RESUME_PROCESS);
>     }
>
>
>
>     // Do this even if instances.xml exists, just to prevent
> all-instances from
>     // getting out of synch.
>     addPRNToAllInstancesDoc(prn);
>     return doc.getDOMDocumentNode();
>
>
>         if (newPid) {
>           // handleEvent filled in the collaboration use.  So that this
>           // case returns the same kinds of collaborations as the case
>           // where the message is enqueued, we null it out before
> returning.
>           event.to().correlation().setCollaborationUse(null);
>         }
>
> I don't think that these could have been avoided by "writing the code
> more clearly".  For example, some are making statements about global
> properties that don't correspond to any one line of code.  Would it be
> better to write these in some kind of formal language that could be
> machine-interpreted for various assorted nice benefits?  Well, I'd be
> interested in checking out a proposed tool/language of that sort...
>
> -- Dan
>