Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!att!cbnewsm!gregk From: gregk@cbnewsm.att.com (gregory.p.kochanski) Newsgroups: comp.object Subject: Re: How to use Inheritance instead of nesting Message-ID: <1990Aug12.134735.22528@cbnewsm.att.com> Date: 12 Aug 90 13:47:35 GMT References: <4800097@m.cs.uiuc.edu> <243@cadlab.sublink.ORG> <5456@stpstn.UUCP> Distribution: usa Organization: AT&T Bell Laboratories Lines: 129 In article <5456@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: >In article <243@cadlab.sublink.ORG> staff@cadlab.sublink.ORG (Alex Martelli) writes: >>I have obviously not yet thought enough about these topics, but it >>seems to me they're deeply connected with the dual nature of class >>inheritance - inheritance of SPECIFICATIONS for an interface, and of >>IMPLEMENTATION... I would welcome a discussion on this, and of MI >>in general. > >My IEEE Software paper (Nov 1990) goes into the distinction between >specification and implementation in some detail... > >Where inheritance really belongs, and where it offers its greatest >potential, is in the (as-yet-nonexistent) specification tools... > >In case this isn't obvious, the meaning I'm using for "specification" >includes not only *static* specifications (i.e. what method names/types >are listed in some interface file; i.e. class Stack has methods push and pop), >but *dynamic* specifications (i.e. if I push 1,2,3 on an instance of class >Stack, pop should return 3,2,1). > >Do you think we should call the new one Subjective-C? ;-) Won't the process of writing the specifications be as complex as writing the program, if you want to specify things in such detail that all operations of a class can be tested? Without attempting to make fun of these ideas -- I think that having even a partial automated testing sceme would be a big improvement-- I'd like to point out that these ideas have already appeared, although not yet implemented: <<< TLE::PUBD$:[VAXNOTES]VAXC.NOTE;1 >>> -< VAX C Notes >- ================================================================================ Note 133.0 Subjective C Revealed No replies REX::MINOW 94 lines 3-APR-1985 09:03 -------------------------------------------------------------------------------- Forwarded from the ARPA AI-LIST for your enjoyment: Date: 1 Apr 1985 16:05:34 EST (Monday) From: PSN Development Subject: subjective C [Forwarded by Susan Bernstein .] Subjective C, a new programming language. Recently researchers in the computer language field have shown much interest in subject oriented languages. Subjective programming languages draw upon concepts developed in the fields of subjective probability and philosophical subjectivism to enrich the field of programming semantics. `Subjective C' is such a language based on the programming language C. Subjective C grew out of the AI concept of DWIM, or "do what I mean". The subjective C compiler infers the mood of the author of the input program based on clues contained in the comments in the program. If no comments (or verbose identifiers) are present, the programmer is judged to have insufficiently thought out his problem, i.e. to have insufficiently specified the computation to be performed. In this case a subjective diagnostic is issued, depending on the compiler's own mood. Assuming comments or other mood indicators are present, an amalgam of inference techniques drawn from various reputed-to-be-successful expert systems are used to infer the author's mood. A trivial example of a mood revealing comment with accompanying program text is the following: a = a - 1; /* add one to a */ A too simple analysis of the dichotomy between apparent meaning of the statement and accompanying comment is that one of them is in error. A more insightful analysis is that this program should not be allowed to work, even if no syntax errors occur in it. Accordingly, subjective compiler should hang the system, thus inducing the programmer to quit for the night. More interesting cases occur when there is no conflict between program text and commentary. It is these cases where Subjective C is shown to be a significantly richer language than normalcy. Some examples of mood-implying comments found in actual programs are the following: ; Here we do something perverse to the packet. Beats me. In this case, the comment reveals that the programmer does not care what the code does, except that he wants it to be something that subsequent programmers will be shocked by. The compiler uses a variation of its mood-inference techniques to generate code that is suitably perverse by systematically generating actions and evaluating them against the criteria it has synthesized. blt ; hold the mayo The Subjective C compiler evaluates the indicatory content of this comment to discern that the programmer is undoubtedly hungry. Code will be generated that will crash inexplicably, thus inducing the programmer to go to the candy machine and pig out, which is what he wanted in the first place. Subjective C is neither a superset nor a subset of "normal" (if one can apply the term) C, known in subjective parlance as normalcy. However, there is an extensive intersection, if meanings of programs are ignored. The central thesis of research in the field of subjective languages is that the meanings of programs are far more subtle than first appears to the reader (or author). Some examples of mood revealing comments in well known C programs include the following: /* I've been powercoding much too much lately. */ and, /* WARNING: modify the following at your own risk. */ Students of program complexity will be interested to note that the algorithms used for mood inference are of greater complexity than NP complete, which is of one of the first known practical applications of this class of computations. The exact characterization of this class of problems is not yet fully explored, but some initial theoretical results will be published by certain graduate students, real soon now, and no later than next August when their fellowships run out. The subjective C compiler, called "see", will be available (relatively) shortly on all bbn unix systems. Comments can be directed directly to the compiler itself, in the usual fashion.