Subject: Re: ISO/IEC CD 13816 -- ISLisp From: Erik Naggum <email@example.com> Date: 1995/12/15 Newsgroups: comp.lang.lisp Message-ID: <19951215T014159Z@arcana.naggum.no> [Atusi Maeda] | New users would find SET-CAR is easier to remember than some cryptic | six-char-limited name. new users find FIRST and REST easier to remember and use than CAR and CDR. if they could use SETF universally, that would also help them remember and use Lisp correctly. since RPLACA and SETCAR are already part of the Lisp tradition, and FIRST and REST were adopted in Common Lisp, I find retention of CAR and CDR while pretending to cater to "new users" somewhat specious. | (CL's DEFINE-SETF-METHOD is a mess). could you elaborate on that? | I believe immutable binding for functions has significant impact on the | implementation techniques. (We can't interactively redefine functions | anymore. Shocking news, eh?) Compiler of ISLisp can always inline | functions safely, or make a simple call instruction (as in C). a Common Lisp compiler can do that with functions in COMMON-LISP, as well. rather than throwing the baby (redefinition) out with the bathwater (lack of static analysis), couldn't ISLisp have provided a facility to freeze packages? (oh, right, it doesn't have packages.) | Assuming function NULL is side-effect free is as dangerous as inlining. assuming that function COMMON-LISP:NULL is side-effect free is perfectly legitimate, as is inlining it. Common Lisp has its good sides, although I recognize the need for inventors of new dialects, especially political creations such as International standards, to slam it. (i.e., a new dialect loses respect according as it is disrespectful of other dialects, from which it should learn, not differ from in bitterness.) | In summary, CALL/CC is way too general. It's actually strictly more | general than GOTOs. We need to restrict the usage of CALL/CC into some | structured way (i.e. only for non-local exit) until we find better way | to tame. is it meaningful to restrict a continuation to be the continuation of a currently active activation? i.e., not allow re-entry to a continuation and no separate life of a continuation apart form the activation records? this would once again make co-routines harder to implement, but that could perhaps be another (related) concept? I find ISLisp a depressing development. it appears unnecessary, and it is gratuitously different from Common Lisp. have you failed to realize that Lispers are facing people who want nothing stronger than to ridicule Lisp because they don't understand it and so don't want to use it? what better weapon to give them than to point out that even Lispers don't want to talk each others' languages? #<Erik 3027980519> -- suppose we actually were immortal... what is the opposite of living your life as if every day were your last?