Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!mcsun!ukc!reading!minster!djs
From: djs@minster.york.ac.uk
Newsgroups: comp.software-eng
Subject: Re: Reuse and Abstraction (was: reu
Message-ID: <643982108.4604@minster.york.ac.uk>
Date: 29 May 90 11:55:08 GMT
References: <4979@stpstn.UUCP> <102100009@p.cs.uiuc.edu> <80449@tut.cis.ohio-state.edu> <19614@duke.cs.duke.edu> <80685@tut.cis.ohio-state.edu> <19760@duke.cs.duke.edu> <80884@tut.cis.ohio-state.edu>
Reply-To: djs@SoftEng.UUCP (djs)
Organization: Department of Computer Science, University of York, England
Lines: 42

In article <80884@tut.cis.ohio-state.edu> Bruce Weide <weide@cis.ohio-state.edu> writes:
>

>> ...  Because of this, one can invent terminology
>>and new notation on the fly, one can leave out essentially uninteresting
>>parts of the specification (like restating over and over again that a
>>particular operation works within the bounds of the type's
>>architecture-specific values), and in general one can play to the
>>audience instead of needing to satisfy a finicky proof-checker.
>
>One of the primary reasons for formal specification is the inherent
>ambiguity of natural language and other informal methods.  It's hard
>to see how having a "formal" notation that can be augmented "on the
>fly" -- whenever the specifier feels a need to say something that the
>language wasn't designed for -- can be much better than an informal
>specification in this sense. 

Augmenting formal specification languages `on the fly' is not necessarily
incorrect. As long as the extensions are understood, and the effect on
the supporting theory are not inconsistent, then augmentations provide
a mechanism for tailoring the language to your own development environment.

No single formal specification language is going to be expressive enough
to ensure applicability to current problems and future ones as well. It
could be argued that providing an easily extensible language is the
only solution to the  `learn-language - evolving-problem - learn new
language'  cycle.

I believe that a RISC approach to specification languages is the way
forward. A core of powerful primitive concepts embedded in a flexible
syntax is much more useful than a `fat' specification language that
tries to freeze all possible solutions in a single complex syntax.
Certainly `on the fly' is an emotive phrase (hacking springs to mind..),
`extensible theory' seems more appropriate.



Dave Scholefield        UUCP       ..!mcsun!ukc!minster!djs
Computer Science Dept.  Internet   djs%minster.york.ac.uk@nfsnet-relay.ac.uk
University Of York
York. YO1 5DD
UK.