Drawing Programs The Theory And Practice Of Schematic Functional Programming

date post
27-Dec-2016
Category

Documents
view
225
download
0

Transcript of Drawing Programs: The Theory and Practice of Schematic Functional Programming

Drawing Programs: The Theory and Practiceof Schematic Functional Programming
Tom Addis Jan Addis

Drawing Programs:The Theory and Practiceof Schematic FunctionalProgramming

123
Tom AddisUniversity of PortsmouthSchool of ComputingPortsmouth P01 3HEUnited Kingdom

Jan AddisClarity SupportSouthsea PO4 9QUUnited Kingdom

ISBN 978-1-84882-617-5 e-ISBN 978-1-84882-618-2DOI 10.1007/978-1-84882-618-2Springer London Dordrecht Heidelberg New York

British Library Cataloguing in Publication DataA catalogue record for this book is available from the British Library

Library of Congress Control Number: 2009927007

Springer-Verlag London Limited 2010Apart from any fair dealing for the purposes of research or private study, or criticism or review, aspermitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced,stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers,or in the case of reprographic reproduction in accordance with the terms of licenses issued by theCopyright Licensing Agency. Enquiries concerning reproduction outside those terms should be sent tothe publishers.The use of registered names, trademarks, etc., in this publication does not imply, even in the absence of aspecific statement, that such names are exempt from the relevant laws and regulations and therefore freefor general use.The publisher makes no representation, express or implied, with regard to the accuracy of the informationcontained in this book and cannot accept any legal responsibility or liability for any errors or omissionsthat may be made.

Cover design: KuenkelLopka GmbH

Printed on acid-free paper

Springer is part of Springer Science+Business Media (www.springer.com)
To David GoodingWho is a good friend and is a colleague who hasenhanced this work with his scholarship. He hasdone more than most to make this book possible.In particular, he listens and engages in realdebate.
Preface

Drawing programs is a personal response to some very practical problems. Toexplain this I need to go back in time to when my greatest toy was the Mechanoset; a mechanical construction kit with instructions on how to build your own toys. Isoon found that although the kit was boundless in one sense it was also very limited.I spent many hours trying to do things that were well beyond the intention of thekit designer. Much later I found electronics where circuits provided me with a muchwider scope for model building but it still took a long time to make devices. It wasnot until programming was introduced during my time at University that this reallyflexible tool was made available. No more bleeding fingers from the iron work andno more burnt ties from soldering irons. Modelling was going to be easy and fun.However, there was snag. I had a natural inability to spell or even to construct coher-ent written sentences. It is true that I had evolved many strategies to successfullyovercome this problem but the strategies only worked within a limited framework.The problem with programs is that they are written and involve the accurate use ofcharacters. Most of my time was spent in pursuing typos and very little time on theprogramming. Sometimes it was necessary to ask someone to look for me and usu-ally they could identify the problem within seconds; natural ability is a wonderfulthing.

Functional programming in the form of LISP came along and the power of thislanguage for expressing formal systems in an elegant way was very exciting. Itwas one move away from having to worry about the actual physical computer withall its storage management problems and one step closer to a language designedspecifically for modelling. It was like stepping into an automatic car after yearsof struggling with manual gears. Even though practical computer languages hadmoved a long way from machine code it was still only a change from the crashgearbox to synchromesh. The computer structure was still in the background in thateverything was forced into the framework of data and processes thus reflecting thefundamental dual distinction within the machine itself. The problem with functionalprogramming was that it was constrained by its own formal framework and stoppedshort of being able to extend itself. LISP overcame this problem, to some extent,by slipping back into the computer framework by introducing special programtype functions. It also overcame another limitation by allowing the language to be

vii
viii Preface

extended beyond the original formal functional description. In some cases it wasstill very clumsy and from my point of view still required being written.

As an engineer, electronic circuits had been no problem to read, to find errorsor to remember. If only programming could be made that easy. It was this drive tocreate a tool that would sidestep issues of spelling and yet still provide a professionaltool for developing models and other kinds of programs. This led us to create Clarity,or rather, led Jan to develop the Clarity environment for me. Also, while we wereat it, we could also eliminate some of the restrictions found in current text-basedlanguages.

Clarity has been introduced quite slowly in this book simply because it seemsto be slightly at odds with the normal windows approach. This is not too surprisingsince it was developed well before windows had become generally available andit was also driven by different requirements. The theory related to designing mod-els has been included right from the beginning but for practical purposes it can beskipped.

The justification for Clarity given in Chapter 1 is in response to criticism ofthe diagrammatic approach to programming. These other diagrammatic approacheshave usually been stimulated by a desire to make programming available to non-programmers. This is not the purpose behind Clarity. Clarity has been driven by aneed to provide a sophisticated tool for programmers that would rather work withdiagrams than with text. Projects are given at the end of each chapter. These followthe style of the Mechano instruction book in that every step is described. The pur-pose of doing it this way is to show how drawing programs should be done and togive an illustration of good techniques.

Clarity has been developed over the last 23 years for a wide range of differentprojects. It evolved out of an IKBS project (CARDS) in 19861990 with the Gen-eral Electric Company, the University of Reading and the Imperial Cancer ResearchFund to build a special hardware device that would allow those involved with DNAresearch to create models of DNA behaviour. For this a modelling language wasneeded. Originally the researchers had used Prolog. The next SERC/ESRC/MRCproject in 19911996 was with the Universities of Bath, with Professor David Good-ing, and the University of Reading with us, to construct a model of scientific discov-ery from the history of science. This work is still going on. Another project startedin 1996 and funded by Ship Analytics (now MPRI, part of the L3 consortium) wasan expert system used as a teacher replacement for Mariners training on a ship sim-ulation for gas and oil management. Work on the automatic assessment of thesestudents is also almost complete. Other work involving modelling of the negotiationprocess (Billinge and Addis 2008) at the University of Portsmouth has come up withsome surprising results requiring us to reconsider the motivation behind reasons forconversation.

We have also taken on some really good post graduate students from the Techni-cal University of Delft, The Netherlands. These have been provided by Dr, Drs LeonRothkrantz almost every year between 1996 and 2006 to work on various projects.Many of these projects have helped to start new research directions such as thosedescribed in Chapter 10. In particular, Dr Bart-Floris Visscher was one of the visit-
Preface ix

ing students who led a team that used Clarity to construct a planning system for amulti-legged robot (Portech Ltd). He was an outstanding student. He came back toPortsmouth to do research with me and his Thesis (2005) Exploring Complexity inSoftware Systems: From an irrational model of software evolution to a theory of psy-chological complexity and cognitive limitations based on empirical evidence wentwell beyond my own work started in 1977. It was thrilling stuff. He also designedthe embellished Clarity icon on the front cover.

There have been many others that have helped us develop the Clarity Environ-ment. Simon Gray (Sharp Edge Systems Ltd) was invaluable at the system levelwhile we working with Apple Macintosh computers and he was always a sourceof new ideas. Dr. Carol Small introduced us to the functional database language(Poulovassilis 1988) during the CARDS project and wrote the core interpreter forthe Sun UNIX system based on Field and Harrisons work (1988). John Chewter, anundergraduate student at the University of Portsmouth, showed considerable pro-gramming aptitude by constructing the Faith to Clarity interpreter for his final yearproject in 1995. It has been surprisingly useful. Ray Gillett (Director, MPRI, UK)has provided us with a set of excellent practical industrial projects since 1998. Theseprojects have not only tested the system to its limits but many of the techniquesdeveloped for the belief system (model of science) have found a natural home. Wethank him for his patience in allowing us to develop the system in our own way.

The Clarity schema has allowed us to work closely with many technically com-petent people. This close working with a fast implementation leads directly tothe models needed. Any system that is useful requires to be continually mod-ified to keep pace with technology and changing perspectives. For this reasonwe a