Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!cis.ohio-state.edu!math.ohio-state.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!sfc-keio-news!mad
From: mad@math.keio.ac.jp (MAEDA Atusi)
Subject: Immutable function bindings (was Re: ISO/IEC CD 13816 -- ISLisp)
In-Reply-To: mad@math.keio.ac.jp's message of Thu, 14 Dec 1995 05:35:51 GMT
Message-ID: <MAD.95Dec21180804@tanzanite.math.keio.ac.jp>
Sender: news@sfc.keio.ac.jp
Nntp-Posting-Host: tanzanite.nak.math.keio.ac.jp
Reply-To: mad@math.keio.ac.jp
Organization: Faculty of Sci. and Tech., Keio Univ., Yokohama, Japan.
References: <49u965$948@goanna.cs.rmit.EDU.AU>
	<MAD.95Dec14143551@tanzanite.math.keio.ac.jp>
	<4as2be$ckp@camelot.ccs.neu.edu>
	<19951215T014159Z@arcana.naggum.no>
	<4b35de$ilh@goanna.cs.rmit.EDU.AU>
Date: Thu, 21 Dec 1995 09:08:04 GMT
Lines: 103

>>>>>> "mad" == MAEDA Atusi Kmad@math.keio.ac.jp> writes:
    mad> Compare this with Scheme.  When executing procedure call (CAR
    mad> something), compiled Scheme code (without dangerous optimization) must
    mad> first fetch the value of the global variable CAR, check that it is a
    mad> procedure, and then invoke it.

>>>>> "will" == William D Clinger <will@ccs.neu.edu> writes:
In article <4as2be$ckp@camelot.ccs.neu.edu> will@ccs.neu.edu (William D Clinger) writes:

    will> This would be true if, like Ada, it were illegal to extend Scheme.
    will> In reality, the Scheme standards state that extensions are legal
    will> so long as they don't conflict with the standards.  In particular,
    will> it is legal to extend Scheme to allow the programmer to specify that
    will> certain procedures should be inlined.  This is, of course, a very
    will> common extension.  Since inlining is done only by permission of the
    will> programmer, it is not a dangerous optimization.

I failed to find out where in R4RS the above statements were made.
Would you please point on the section?  Or is that in IEEE Standard?

About functions in COMMON-LISP package, yes, I was out-of-date, for
around ten years.  I should have read CLtL2 more carefully.

About user-defined functions, there are three approaches.

  1. Include (DECLARE (INLINE ...)) in standard, or allow equivalent
     extension to implementation.  Functions can be redefined.  
     Redefinition affects other functions that calls redefined one
     unless redefined functions are declared to be inlined.
  2. No (DECLARE (INLINE ...)) and functions can be redefined.
  3. No (DECLARE (INLINE ...)) and functions can't be redefined.

Common Lisp and Scheme takes the first approach and ISLisp the third.
If both approach can achieve efficiency of almost same level, then
what is the difference?  Programmers should add in Common Lisp
programs or Scheme programs to gain maximum efficiency (this may be
trivial).  Compilers of Common Lisp or Scheme will be complicated
compared to ISLisp, to support multiple linkage method (it may also be
a Small Matter Of Programming, but difference is difference).

ISLisp's approach has a big disadvantage.  Although the draft states
that it does not specify how to prepare an ISLisp text for execution
and how to execute it, the fact that it forbids redefinition of
functions effectively kills the usefulness of READ-EVAL-PRINT style
interpreters.  Toplevel loop for ISLisp, if exists, will look more like
GDB command line rather than ordinary Lisp environment.

How about ease of distribution and installation of applications?
Now I must admit that I don't know how commercial Lisp programs are
distributed.  Are applications distributed as stand-alone programs?
Or must users have entire Lisp system in advance?

>>>>> "ok" == Richard A O'Keefe <ok@goanna.cs.rmit.EDU.AU> writes:

    (On MAEDA's statements saying "calling redefinable functions requires
    run-time checking".)
    ok> The claim that this _must_ be done is simply false.  What you _do_ need is
    ok> a good module system (which could certainly be added to Scheme without
    ok> breaking anything except a few reserved words; there are several proposals
    ok> around) so that the compiler can know when it is compiling a particular
    ok> module that every other module _can't_ assign to this variable and that this
    ok> module _doesn't_.  It's not even hard.

>>>>ernet.media-coverage

    (In reply to MAEDA's statements saying "ISLisp compilers can always
    inline function calls".)
    erik> rather than throwing the baby (redefinition) out with the bathwater (lack
    erik> of static analysis), couldn't ISLisp have provided a facility to freeze
    erik> packages?  (oh, right, it doesn't have packages.)

ISLisp does need module facility, as I wrote in my article
<MAD.95Dec14163948@tanzanite.math.keio.ac.jp>.

It should differ from Common Lisp packages, though.  (CL packages
solve name clash, but they don't provide encapsulation.  Internal
symbols can be freely accessed via qualified names.)

    ok> One thing I have learned to dislike is environments where the debugging
    ok> environment has different semantics from the production environment.  For
    ok> example, if functions _can_ be redefined somehow in the debugging
    ok> environment but not in the production environment, then you are debugging
    ok> a different language from the one your shipped application is written in.

Well, I thought having both interpreter and compiler makes debugging
easier.  Following your opinion, switching compiler settings or adding
declarations to programs both change the language, then.  So can this
be counted as an advantage of ISLisp?

    ok> Oh yes, the idea that function calls can _always_ be mapped to a simple
    ok> call instruction in C is quite a few years behind the times.  Windows,
    ok> OS/2, VMS, and modern UNIX systems, all have some form of dynamic linking.

My point is that calls to redefinable Scheme functions may add extra
indirection in addition to the ones required by OS's dynamic link.  Of
course, you can avoid it by throwing away assemblers and linkers
provided by OS and reimplementing it by yourself.  Another SMOP.

;;;  Keio University
;;;    Faculty of Science and Technology
;;;      Department of Math
;;;		MAEDA Atusi (MAEDA is my family name)
;;;		mad@math.keio.ac.jp
