Path: utzoo!news-server.csri.toronto.edu!rutgers!sun-barr!lll-winken!uunet!mcsun!ukc!edcastle!aiai!jeff From: jeff@aiai.ed.ac.uk (Jeff Dalton) Newsgroups: comp.lang.scheme Subject: Re: To Lisp, or not to Lisp; that is the question. Message-ID: <4321@skye.ed.ac.uk> Date: 15 Mar 91 20:06:31 GMT References: <9103120750.AA00865@kuwait> <458@data.UUCP> Reply-To: jeff@aiai.UUCP (Jeff Dalton) Organization: AIAI, University of Edinburgh, Scotland Lines: 37 In article <458@data.UUCP> kend@data.UUCP (Ken Dickey) writes: >>Recall Dalton's concern that classifying too many important parts >>of a language/world as environment drastically reduces portability. > >I don't see that "the classification" (making distinctions) reduces >portability. It is the lack of standards that reduces portability! I >have been taking a "constructive" view in trying to separate standards >for "language", "runtime system library", "development system", etc., >*all* of which are important. It is the lack of agreement between implementations that reduces portability. One reason for classifying something as "environment" as distinct from language is to allow implementations of the same language to provide different environments. Having a separate environment standard may be a good idea, but it would still be the case that implementations of the language would not have to conform to the environment standard. >I certainly want to be able to add new data types (e.g. Windows) to >Scheme by augmenting I don't feel that this changes the "language". It is possible to make a number of different distinctions between "langauge" and "library", just as it is possible between language and environment. In C, for example, arithmetic is not part of the library. In some Lisp, it just might be. >However, when I want to write portable Scheme code in industry, I want >to use an implementation which conforms to "the portable development >standard" and guarentees base-line functionality and interfaces (level >5?). It helps to keep the number of possible permutations small. -- jeff