Subject: Re: ISO/IEC CD 13816 -- ISLisp
From: Erik Naggum <erik@naggum.no>
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?