Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@test.aber.ac.uk (Piercarlo Antonio Grandi) Newsgroups: comp.lang.misc Subject: Re: A comment on language wars. Message-ID: Date: 11 Mar 91 16:39:37 GMT References: <7HY9P4G@xds13.ferranti.com> <1991Mar10.145908.10575@hawk.cs.ukans.edu> <9053@castle.ed.ac.uk> Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 31 Nntp-Posting-Host: aberdb In-reply-to: aipdc@castle.ed.ac.uk's message of 11 Mar 91 00:35:47 GMT On 11 Mar 91 00:35:47 GMT, aipdc@castle.ed.ac.uk (Paul Crowley) said: aipdc> In article <1991Mar10.145908.10575@hawk.cs.ukans.edu> aipdc> billk@hawk.cs.ukans.edu (Bill Kinnersley) writes: billk> Definition of an interpreter: billk> A case statement inside a do loop. Quoting myself from long ago: *all* programs are hierarchies of interpreters. All programs are composed of modules each of which is an interpreter. An interpreter is composed fo some code (the glue) that navigates some data structure and examines each of its elements, and of some code (the library) that provides the ways to handle each element of that data structure. Either glue or library may be trivial or implicit, of course. Important note: the above definition implies that *control* abstraction is vital to implementing glue, while *data* abstraction is vital to implementing library functions. OO programming only provides the latter. Research on control abstraction is very rare. aipdc> Corollary: Most X programs are interpreters. Well, so much so than most other things. Yes, definitely the X server is an interpreter, or rather, a hierarchy of interpreters. I'd say that X clients programs are interpreters, even xclock (it interprets just one instruction). -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk