Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!fas-news.harvard.edu!newspump.wustl.edu!news.ecn.bgu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!newsfeed.internetmci.com!news.dacom.co.kr!usenet.seri.re.kr!news.imnet.ad.jp!wnoc-tyo-news!wnoc-sfc-news!kogwy!math-keio!mad
From: mad@math.keio.ac.jp (MAEDA Atusi)
Subject: Re: ISO/IEC CD 13816 -- ISLisp
In-Reply-To: ok@goanna.cs.rmit.EDU.AU's message of 4 Dec 1995 18:49:25 +1100
Message-ID: <MAD.95Dec14143551@tanzanite.math.keio.ac.jp>
Sender: news@math.keio.ac.jp
Nntp-Posting-Host: tanzanite
Reply-To: mad@math.keio.ac.jp
Organization: Faculty of Sci. and Tech., Keio Univ., Yokohama, Japan.
References: <19951126T160911Z@naggum.no> <49a79n$p2q@cantaloupe.srv.cs.cmu.edu>
	<49fvok$p46@nz12.rz.uni-karlsruhe.de>
	<49o7ee$bkl@cantaloupe.srv.cs.cmu.edu>
	<49u965$948@goanna.cs.rmit.EDU.AU>
Date: Thu, 14 Dec 1995 05:35:51 GMT
Lines: 109

>>>>> "ok" == Richard A O'Keefe <ok@goanna.cs.rmit.EDU.AU> writes:
In article <49u965$948@goanna.cs.rmit.EDU.AU> ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes:

    ok> Who precisely is helped by renaming RPLACA to SET-CAR

New users would find SET-CAR is easier to remember than some cryptic
six-char-limited name.

    ok> If you don't like the name RPLACA, just leave it out, (SETF (CAR ..) ..)
    ok> will do fine.

Maybe.  But many implementations would have something like that
anyway.  CMU CL has COMMON-LISP::%RPLACA, CLISP has SYSTEM::%RPLACA,
Allegro has EXCL::.INV-CAR, and so on.  Note that SET-CAR is
incompatible with RPLACA in its argument order and return value.  It
shares convention with other setter functions such as SET-PROPERTY,
SET-AREF, etc.  And it gives user a concrete idea of what SETF is
doing.  (CL's DEFINE-SETF-METHOD is a mess).

    [deleted...]
    ok> 2.  How easy is it to _implement_ something?
    [deleted..]

    ok>     I am not up to speed on current Lisp compilation techniques, but I
    ok>     really do get a strong impression that writing a really good compiler
    ok>     for ISlisp is not _significantly_ simpler than writing a really good
    ok>     compiler for Common Lisp.

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).

Compare this with Scheme.  When executing procedure call (CAR
something), compiled Scheme code (without dangerous optimization) must
first fetch the value of the global variable CAR, check that it is a
procedure, and then invoke it.

This check can be omitted in Common Lisp (because of its separate
namespace for functions), but the call must be done indirectly to
retain redefinability.  Inlining functions loses redefinability in
Common Lisp. Compiled code with (DECLARE (INLINE FOO) can't reflect
later changes on FOO, for example.  This also defeats possibility of
interprocedural side-effect analysis.  Assuming function NULL is
side-effect free is as dangerous as inlining.

Local functions are easier to handle in Common Lisp, because they
cannot be redefined within their scope.  In Scheme, however,
LETREC-bound variables can be modified with SET!.  So compiler must
first prove that the value is a procedure at the time of invocation
before emitting direct call instruction.

    ok>     There is no call-with-current-continuation (so much for learning from
    ok>     Scheme).  Nor are there multiple values.  (Which _are_ in R5RS Scheme.)

CALL-WITH-CURRENT-CONTINUATION, aside from its implementation
difficulty per se, has some drawbacks.

* UNWIND-PROTECT no longer works with it.  The following code:
	(UNWIND-PROTECT
	  <some file processing>
	  (CLOSE FILE))
  looks okay.  But what will happen if someone captured continuation
  inside <some file processing> and try to resume processing later?

  Note that UNWIND-PROTECT is crucial in writing real-world
  applications.

* CALL/CC defeats some compiler optimizations.
  Without CALL/CC,
      (LET ((A ..) (B ..))
        ..
	(LET ((X (CONS A B)))
	  (FOO)
	  X) ..)
  can be safely transformed into:
       (LET ((A ..) (B ..))
        ..
	(PROGN
	  (FOO)
	  (CONS A B) ..)
  Here, A and B are lexical variables and FOO can't affect the values
  thereof.  With CALL/CC, the transformation above is not safe (if
  continuation is caputured in FOO and invoked many times, the former
  always returns identical cons cell but the latter doesn't).

  Similary,
    (LET ((A ..))
        ..
	(LET ((X A))
	  (FOO)
	  (SETQ X (+ X 1)))
        ..)
  cannot be transformed into:
    (LET ((A ..))
        ..
	(PROGN
	  (FOO)
	  (+ A 1))
        ..)
  in the presence of CALL/CC.

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.

				--mad
