rees@parc.xerox.COM (08/22/90)
Date: Tue, 21 Aug 1990 02:45:28 PDT
From: Kellom{ki Pertti <pk%tut.uucp%tut.uucp%sunic.uucp%luth.uucp%eru.uucp@bloom-beacon.mit.edu>
Before resorting to the "Scheme without call/cc is not Scheme"
argument (with which I quite agree), remember that an embedded
extension language is not used as a general purpose programming
language, so the ability to be able to run all the call/cc puzzles is
not of prime importance.
While I agree with the conclusion, I strongly object to the argument.
This claim about how embedded extension languages will be used has
been proven wrong over and over again, much to the anguish of users:
witness TeX, VMS DCL, Unix shells, C preprocessor. It is simply
inevitable that users will want "general purpose" power (abstraction,
compilability) in purportedly special purpose languages. Usually what
happens to a special purpose language is that user pressures force
addition of features that don't fit very well into the original
framework, and you end up with a horrible mess: piles of exceptions,
multiple mechanisms for doing the same thing, etc. To prevent this,
you've got to design a language from the beginning so that even if it
doesn't start out being general-purpose, at least it can grow into
general-purposeness gracefully.
Not all uses of CWCC are puzzles, but I agree with Guy that it is of
secondary importance relative to other features. (My flame about SIOD
was strictly about its conformance with R3RS, not about its useability
or its Schemeness.)
Jonathanjanssen@parc.xerox.com (Bill Janssen) (08/22/90)
In article <9008211819.AA11007@satchmo> rees@parc.xerox.COM writes:
Date: Tue, 21 Aug 1990 02:45:28 PDT
From: Kellom{ki Pertti <pk%tut.uucp%tut.uucp%sunic.uucp%luth.uucp%eru.uucp@bloom-beacon.mit.edu>
Before resorting to the "Scheme without call/cc is not Scheme"
argument (with which I quite agree), remember that an embedded
extension language is not used as a general purpose programming
language, so the ability to be able to run all the call/cc puzzles is
not of prime importance.
While I agree with the conclusion, I strongly object to the argument.
This claim about how embedded extension languages will be used has
been proven wrong over and over again, much to the anguish of users:
witness TeX, VMS DCL, Unix shells, C preprocessor. It is simply
inevitable that users will want "general purpose" power (abstraction,
compilability) in purportedly special purpose languages. Usually what
happens to a special purpose language is that user pressures force
addition of features that don't fit very well into the original
framework, and you end up with a horrible mess: piles of exceptions,
multiple mechanisms for doing the same thing, etc. To prevent this,
you've got to design a language from the beginning so that even if it
doesn't start out being general-purpose, at least it can grow into
general-purposeness gracefully.
Absolutely correct.
--
Bill Janssen janssen@parc.xerox.com (415) 494-4763
Xerox Palo Alto Research Center
3333 Coyote Hill Road, Palo Alto, California 94304peter@ficc.ferranti.com (Peter da Silva) (08/23/90)
In article <9008211819.AA11007@satchmo> rees@parc.xerox.COM writes: > It is simply > inevitable that users will want "general purpose" power (abstraction, > compilability) in purportedly special purpose languages. Which is the whole point of having general purpose, convenient, and easily extended languages that can be packaged into programs, like SIOD, TCL, and so on... > Usually what > happens to a special purpose language is that user pressures force > addition of features that don't fit very well into the original > framework, and you end up with a horrible mess: piles of exceptions, > multiple mechanisms for doing the same thing, etc. You mean like REXX? -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com