sokolov@mit-amt (Michael Sokolov) (10/20/88)
In article <589@dcl-csvax.comp.lancs.ac.uk> simon@comp.lancs.ac.uk (Simon Brooke) writes: > And if we aren't allowed to redefine the way the top-level read - eval >- print loop works, then the language certainly isn't as expressive: there is >a large category of things it can't express. It is still possible to redefine the way the read-eval-print loop works; you just have to wrap your own read-eval-print loop around the lisp's, making sure to include an unwind-protect so that your loop won't get aborted out of. The only tricky thing is that you may have to write an s-expression parser to do this just right, but without the niceties: (defun repl () (tagbody spot (format t "~%~A" *prompt*) (let (val) (unwind-protect (loop (setq val (eval (read))) (format t "~S" val) (format t "~%~A" *prompt*)) (go spot))))) You can replace the call to eval in this function with a call to your favorite evaluator! Once you evaluate "(repl)" it never returns. MS
simon@comp.lancs.ac.uk (Simon Brooke) (10/25/88)
In article <3185@mit-amt> sokolov@media-lab.media.mit.edu (Michael Sokolov) writes: >In article <589@dcl-csvax.comp.lancs.ac.uk> simon@comp.lancs.ac.uk (Simon Brooke) writes: > >> And if we aren't allowed to redefine the way the top-level read - eval >>- print loop works, then the language certainly isn't as expressive: there is >>a large category of things it can't express. > > It is still possible to redefine the way the read-eval-print >loop works; you just have to wrap your own read-eval-print loop around >the lisp's, making sure to include an unwind-protect so that your loop >won't get aborted out of. The only tricky thing is that you may have >to write an s-expression parser to do this just right, but without the >niceties: > Yes, ok, there are butchers jobs you can use to work round any barbarity. That is, with respect, not the point. The ANSI Common LISP committee has already done immeasurable damage to a language which is quite as much my property as theirs. Unfortunately, they have hegemony, and eventually my customers are going to force me to use their abomination because it is 'the standard'. They now propose a futher barbarity: they propose to alter the system so that a class of function symbols has a different semantics from all other function symbols. This *cannot* be a good thing to do! The elegance and power of LISP lie precisely in its simple, general semantics, and in its malleability. If the ANSI Lisp committee want to write in FORTRAN, that's fine, let them. BUT LEAVE MY LANGUAGE ALONE! ** Simon Brooke ********************************************************* * ___ * * // \\ Common Knowledge Ltd. * * || X Moor Lane Mills, Moor Lane, Lancaster LA 1 3 QD * * \\_// * *************************************************************************
jeff@aiva.ed.ac.uk (Jeff Dalton) (10/27/88)
In article <593@dcl-csvax.comp.lancs.ac.uk> simon@comp.lancs.ac.uk (Simon Brooke) writes: >> It is still possible to redefine the way the read-eval-print >>loop works; you just have to wrap your own read-eval-print loop >Yes, ok, there are butchers jobs you can use to work round any barbarity. I am not convinced that redefining EVAL is the best way to get a different repl. Indeed, writing a new loop is often a better way. > They now propose a futher barbarity: they propose to alter the > system so that a class of function symbols has a different semantics > from all other function symbols. This *cannot* be a good thing to do! It prevents you from breaking the Lisp unintentionally and it prevents you from thinking you have code that will work in more than one implementation when you don't. So there are points on both sides. Besides, suppose they let you lock a package in the same way that the Lisp package would be locked. Then the no-redefinition semantics for the Lisp package would not be a special case. > The elegance and power of LISP lie precisely in its simple, general > semantics, and in its malleability. Well, suppose you redefine some function. How do you know what other functions will see that redefinition and what ones will not? If you redefine EVAL, will it change the behavior of LOAD? Historically the answer has been: it depends on the implementation. I have yet to see a specification for a Lisp *as a language rather than as an implementation* that described what happened in all these cases. Redefining built-in procedures generally has unpredictable consequences. Sometimes, everything falls apart. Other times, it has surprisingly little effect. Getting the exact reaults you want is generally impossible except where you know the details of a particular implementation. And particular implementations might not have let your redefinitions have any effect in any case. (Imagine, for example, that everything is "block compiled" so that redefinitions are never seen by internal calls. You could redefine EVAL then and it wouldn't even change the repl.) So what, exactly, do you want? Do you want CL to leave this area unspecified? Do you want a specification of exactly what happens in every case? Or do you just want the top-level loop defined in such a way that you can change the read, eval, and print parts? > If the ANSI Lisp committee want to write in FORTRAN, that's fine, But they don't want to write in FORTRAN, they want to write in Common Lisp. -- Jeff
Krulwich-Bruce@cs.yale.edu (Bruce Krulwich) (11/01/88)
In article <593@dcl-csvax.comp.lancs.ac.uk>, simon@comp (Simon Brooke) writes: >They now propose a futher barbarity: they propose to alter the >system so that a class of function symbols has a different semantics from all >other function symbols. This *cannot* be a good thing to do! The elegance >and power of LISP lie precisely in its simple, general semantics, and in its >malleability. If the ANSI Lisp committee want to write in FORTRAN, that's >fine, let them. BUT LEAVE MY LANGUAGE ALONE! As I understand it, they have not made ANY changes to the semantics of the language or of the set of function symbols. All that has been proposed is that the functions that are part of the language definition be effectively declared INLINE. (ie, that they can be changed but that the changes may not propogate to all of their uses.) Any problems that you have with the changes are in fact problems with the semantics of INLINE. On the other hand, the analogy between CL and Fortran may have some basis. Issues such as the seperation of function and value slots seem to be decided by arguments such as "that's the way it's always been" and "that's the way the implementations all work" and not "that's the better way to do it." Bruce
barmar@think.COM (Barry Margolin) (11/01/88)
In article <41800@yale-celray.yale.UUCP> Krulwich-Bruce@cs.yale.edu (Bruce Krulwich) writes: > All that has been proposed is >that the functions that are part of the language definition be effectively >declared INLINE. (ie, that they can be changed but that the changes may >not propogate to all of their uses.) Not really. An ordinary INLINE declaration can be lexically overridden by a local NOTINLINE declaration. (declare (notline eval)) is not guaranteed to get around this particular issue. Also, the other issue of redefining standard functions it the undefined effect it will have on other standard functions. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar