pk@tut.fi (Kellom{ki Pertti) (08/21/90)
There has been at times quite heated discussion about small Scheme (or
schemish lisp) implementations. One point that that was raised by
Niels Mayer was that Scheme as well as other small lisps would be a
good choice for an extension language, because of the existing
literature, support etc. that an already existing language has.
Although I like the idea of continuations, it seems that for an
extension language a'la Emacs Lisp they are a bit of overkill, because
of the extra implementation and runtime difficulties involved. For
most applications, "almost first class" continuations would be quite
sufficient. What I'm thinking of is some kind of catch-throw like
mechanism that could be expressed in terms of call/cc but implemented
more efficiently. This kind of subset would be enough for typical
(all?) uses of an extension language, while being compatible with
Scheme in the sense that all programs written using the subset could
be run using a "real" Scheme.
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.
--
Pertti Kellom\"aki (TeX format) # These opinions are mine,
Tampere Univ. of TeXnology # ALL MINE !
Software Systems Lab # (but go ahead and use them, if you like)markf@ZURICH.AI.MIT.EDU (08/21/90)
In <PK.90Aug21114528@kaarne.tut.fi> Kellom{ki Pertti writes: >> Although I like the idea of continuations, it seems that for an >> extension language a'la Emacs Lisp they are a bit of overkill >> ... >> remember that an embedded >> extension language is not used as a general purpose programming >> language I worry a little about this sort of attitude because I see it in the plethora of horrendous extension languages that I have to deal with every day. TeX, Postscript(tm), C-shell ... I imagine that their designers all figured that they didn't need this or that feature of "real" programming languages and the rest of us have to suffer for their imaginations. It may be resonable to leave out some of the derivable procedures (and special forms if we ever have macros) since their importance comes more from portablility concerns than expressibility, but the usefulness of extension languages lies at least in part in our inability to envision the fascinating ways that users will extend our prosiac applications. I think that those users (and we, of course) deserve the best tools for creating those fascinating uses. -Mark Mark Friedman MIT Artificial Intelligence Lab 545 Technology Sq. Cambridge, Ma. 02139 markf@zurich.ai.mit.edu
net@tub.UUCP (Oliver Laumann) (08/22/90)
In article <PK.90Aug21114528@kaarne.tut.fi> pk@tut.fi (Kellom{ki Pertti) writes: > For most applications, "almost first class" continuations would be quite > sufficient. What I'm thinking of is some kind of catch-throw like mechanism The distinction here is not first-class versus non-first-class continuations, but "downward" versus "upward" continuations, as I have just learned with the friendly help of some Lisp experts. "Downward" continuations are those equivalent to Lisp's catch/throw (and usually easy to implement, e.g. by means of setjmp/longjmp in C or by means of catch/throw in Lisp); "upward" continuations are those like the one returned by the function "f" below: (define (f) (call-with-current-continuation (lambda (c) c))) While we're at it-- I'm just working on a version of the Extension Language Kit (Elk) that doesn't require assembly language code any longer (and thus can be ported to new machines easily), but will only support downward continuations in this case. -- Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP
pk@tut.fi (Kellom{ki Pertti) (08/22/90)
>>>>> On 21 Aug 90 15:40:13 GMT, markf@ZURICH.AI.MIT.EDU said: markf> In <PK.90Aug21114528@kaarne.tut.fi> Kellom{ki Pertti writes: >> remember that an embedded >> extension language is not used as a general purpose programming >> language markf> I worry a little about this sort of attitude because I see it in the markf> plethora of horrendous extension languages that I have to deal with markf> every day. TeX, Postscript(tm), C-shell ... I imagine that their markf> designers all figured that they didn't need this or that feature of markf> "real" programming languages and the rest of us have to suffer for markf> their imaginations. This is why I would like to see Scheme used as an extension language. Scheme without a fully general call/cc (that is, without upward continuations, as Oliver Laumann pointed out) is a quite powerful programming language. The problem boils pretty much down to what gjc@mitech.COM said: >>>>> On 22 Aug 90 02:25:36 GMT, gjc@mitech.COM said: gjc> I would point out that fully general CALL/CC is one of those gjc> things that flies in the face even the extremely general gjc> VAX/VMS model of runtime-language support. gjc> Why? One reason is that CONDITION-HANDLING, the ability to undo side-effects gjc> while unwinding the stack, and the ability to dynamically scope the gjc> handling of machine and software generated exception cases, including gjc> instruction emulation, is very important to the workings of things. gjc> If you have a call sequence like: gjc> C->SCHEME->C->SCHEME->FORTRAN->PASCAL->SCHEME gjc> 1 2 3 4 5 6 7 gjc> you are up shits creek if you think that you can return a fully gjc> general lexical catch construct from level 7 back up to level 2 gjc> and then expect to re-enter the damn thing. This kind of calling sequence is something that I would expect to see being used when Scheme is used as an extension language. The reason why I proposed a catch-throw like mechanism is that I would rather see something that clearly states that it is not a general call/cc, rather than having a call/cc that works almost, but not quite like it should work. -- Pertti Kellom\"aki (TeX format) # These opinions are mine, Tampere Univ. of TeXnology # ALL MINE ! Software Systems Lab # (but go ahead and use them, if you like)
vladimir@prosper.Eng.Sun.COM (Vladimir G. Ivanovic) (08/23/90)
From the abstract of "Tcl: An Embeddable Command Language" by John Ousterhout, UC Berkeley: Tcl is an interpreter for a tool command language. It consists of a library package that is embedded in tools (such as editors, debuggers, etc) as the basic command interpreter. Tcl provides (a) a parser for a simple textual command language, (b) a collection of built-in utility commands, (c) a C interface that tools use to augment the built-in commands with tool-specific commands. Tcl is particularly attractive when integrated with the widget library of a window system: it increases the programmability of the widgets by providing mechanisms for variables, procedures, expressions, etc; it allows users to program both the appearance and the actions of widgets; and it offers a simple but powerful communication mechanism between interactive programs. ------ Tcl and mx, the editor built using Tcl are available using autonomous ftp from ucbvax.berkeley.edu in the file pub/mx.tar.Z. There is also tcl.tar.Z which contains only the Tcl code. A copy of the paper cited is in the tcl directory as usenix.ps (I think). My sense is that the ideas that Tcl uses are worthy of serious consideration as a better paradigm of an extension/command language compared to Scheme. Mind you, there a lots of applications where Scheme is THE language of choice, where Tcl would be totally inappropriate, but I don't think a generic extension language is one of them. -- Vladimir -- Vladimir G. Ivanovic vladimir@prosper.Eng.Sun.COM Sun Microsystems, Inc. or (415) 336-2315 vivanovic@Sun.COM
peter@ficc.ferranti.com (Peter da Silva) (08/24/90)
In article <VLADIMIR.90Aug23024039@prosper.Eng.Sun.COM> vladimir@prosper.Eng.Sun.COM (Vladimir G. Ivanovic) writes: > Tcl is an interpreter for a tool command language. ... > My sense is that the ideas that Tcl uses are worthy of serious consideration > as a better paradigm of an extension/command language compared to Scheme. It's easier on the user, but because it requires you to continually copy and re-parse strings performance is a problem. It's fast enough to manage keystrokes, but a stream of MIDI data can't be piped through it if you want to keep up. TCL is sort of a cross between Lisp and such string-oriented interpreted languages as "awk". I use it in my UNIX directory browser program, "browse". -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
kend@data.UUCP (Ken Dickey) (08/28/90)
pk@tut.fi (Kellom{ki Pertti) writes: ... >Although I like the idea of continuations, it seems that for an >extension language a'la Emacs Lisp they are a bit of overkill, because >of the extra implementation and runtime difficulties involved. For >most applications, "almost first class" continuations would be quite >sufficient. What I'm thinking of is some kind of catch-throw like >mechanism that could be expressed in terms of call/cc but implemented >more efficiently. This kind of subset would be enough for typical >(all?) uses of an extension language, while being compatible with >Scheme in the sense that all programs written using the subset could >be run using a "real" Scheme. >Before resorting to the "Scheme without call/cc is not Scheme" >argument (with which I quite agree), ... Yes, yes, yes! This point was raised during one of the IEEE Scheme Standard meetings. My recollection of the majority view at that meeting was that having e.g. Level 0 Scheme [without call/cc]..Level-N Scheme [full numeric tower+] was that it would cloud the issue of "What do you get when you get a Standard Scheme implementation?". If you have Scheme with Catch & Throw, but without Call/CC, *don't* call it "Scheme" [How about "Sub-Scheme" 8^]. {Seriously, if you need co-routines, non-blind backtracking, or have a timer interrupt and want to do multi-tasking, continuations are most useful. The implementation is not hard if you are doing an interpreter and efficient runtime implementation technology for compiled systems is well known.} [Just agreeing loudly; you could have hit `N' ] -Ken kend@data.uucp
peter@ficc.ferranti.com (Peter da Silva) (08/29/90)
> {Seriously, if you need co-routines, non-blind backtracking, or have a > timer interrupt and want to do multi-tasking, continuations are most > useful. The implementation is not hard if you are doing an > interpreter and efficient runtime implementation technology for > compiled systems is well known.} "Montage is not a proactical system. The CALL/CC construct of Scheme, while powerful and portable, does not acheive the performance necessary for the near real-time constraints that a window system imposes. Specifically, in every one of the dozen Scheme implementations that I have tested CALL/CC allocates so much memory that most of the run time is spent in the garbage collector." -- Paul Haahr, "Montage: Breaking windows into small pieces", USENIX conferance proceedings, Jun 11-15, 1990. This is exactly the environment an extension language is needed for. For what you need CALL/CC for in such a program CALL/CC is not fast enough. Thus I would consider CALL/CC to be a luxury in this environment. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
jeff@aiai.edinburgh.ac.UK (Jeff Dalton) (08/30/90)
> >Before resorting to the "Scheme without call/cc is not Scheme" > >argument (with which I quite agree), ... > > Yes, yes, yes! > > This point was raised during one of the IEEE Scheme Standard meetings. > My recollection of the majority view at that meeting was that having > e.g. Level 0 Scheme [without call/cc]..Level-N Scheme [full numeric > tower+] was that it would cloud the issue of "What do you get when you > get a Standard Scheme implementation?". This is the question of whether the IEEE std should have layers of a certain sort, *not* whether a language w/o call/cc should be called "Scheme". Note that they way standards usually work is that implementations can differ from the std provided that the differences are documented. > If you have Scheme with Catch & Throw, but without Call/CC, *don't* call > it "Scheme" [How about "Sub-Scheme" 8^]. I would rather have langauges w/o call/cc called "Scheme" than have lose out to other languages because it must always implement full call/cc.
peb@Autodesk.COM (Paul Baclaski) (09/18/90)
In article <AXI5NUG@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > ... Specifically, in every one of > the dozen Scheme implementations that I have tested CALL/CC > allocates so much memory that most of the run time is spent > in the garbage collector." > -- Paul Haahr, > "Montage: Breaking windows into small pieces", > USENIX conferance proceedings, Jun 11-15, 1990. > > This is exactly the environment an extension language is needed for. For > what you need CALL/CC for in such a program CALL/CC is not fast enough. > Thus I would consider CALL/CC to be a luxury in this environment. See "Representing Control in the Presence of First-Class Continuations" by R. Hieb, R. K. Dybvig, Carl Bruggeman in ACM SIGPLAN '90 Conference Proceedings, pp. 66-77. They present an excellent analysis of the tradeoffs involved in implementing call/cc and describe a new method for implementing it that does not have unbounded copying or a high procedure invocation cost. Apparently, Chez Scheme implements their new method. Paul E. Baclaski peb@autodesk.com