From: Jeffrey Mark Siskind
Subject: Re: ISO/IEC CD 13816 -- ISLisp
Date:
Message-ID: <QOBI.95Dec18105807@qobi.ai>
In article <·················@tanzanite.math.keio.ac.jp> ···@math.keio.ac.jp (MAEDA Atusi) writes:
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.
The Stalin compiler for Scheme does sound automatic inlining without
declarations. It safely compiles all Scheme procedure calls into direct C
function calls, even when the call is higher-order. It safely eliminates the
runtime check that the callee is a procedure when it can determine by compile
time type analysis that the callee must be a procedure of the correct arity.
In practise, it can do this in almost all cases, even for higher-order
procedures.
* CALL/CC defeats some compiler optimizations.
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.
Stalin can determine when and where in a program CALL/CC is used and
continuations called. It can determine on an expression by expression basis
whether or not that expression can be reentered by calling a continuation.
The fact that the language supports CALL/CC causes no penalty whatsoever for
programs that do not use it. And even for programs that do use it, there is no
penalty whatsoever for those portions of the program that do no use it.
Stalin automatically determines when it is sound to compile calls to CALL/CC
and continuations as simple goto statements, when it needs to use
setjmp/long, and when it needs to resort to CPS conversion. It does this on an
expression by expression basis, independently for each call to CALL/CC and
each continuation call. And this is all soundly integrated with procedure call
inlining and type analysis.
In my experience, there is nothing in the R4RS Scheme language that cannot be
compiled as efficiently as C given sufficient resources to write a good
compiler and sufficient resources to run such a compiler.
Jeff (home page http://www.cs.toronto.edu/~qobi)
--
Jeff (home page http://www.cs.toronto.edu/~qobi)
From: Fernando D. Mato Mira
Subject: ISO on Common (was: ISO/IEC CD 13816 -- ISLisp)
Date:
Message-ID: <4b9o38$6rl@info.epfl.ch>
What hurdles, if any, exist to implement ISO Lisp as a thin layer
of macrology on top of Common Lisp?
--
Fernando D. Mato Mira http://ligwww.epfl.ch/matomira.html
Computer Graphics Lab
Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248
CH-1015 Lausanne FAX : +41 (21) 693 - 5328
Switzerland E-mail : ········@di.epfl.ch
[Fernando D. Mato Mira]
| What hurdles, if any, exist to implement ISO Lisp as a thin layer
| of macrology on top of Common Lisp?
I see this as implying that it would be desirable to have a Common Lisp
package that implemented ISLisp.
if I may stretch the idea, I think one should _define_ International
Standard Lisp as a package that can be referenced in existing Lisp systems
(probably several, not just the _standard_ ones). this is not a trivial
exercise, but keeping with the spirit of the Norwegian suggestion (mine,
actually, although it was not as new in the real world as it was to ISO <--
understatement) during discussions about the procedures of ISO recognition
of Publicly Accessible Specifications (PAS), which was adopted with much
less enthusiasm than I had hoped (essentially "yeah, great idea. what's
the next item?"), that ISO standards should have a free reference
implementation before they were fully adopted.
C++ got jump-started by free-loading on C compilers, a devilishly clever
move in retrospect, but probably one of necessity at the time. similarly,
I don't think ISLisp has _any_ chance of becoming a winning standard Lisp
unless it is piggy-backing on previous work and available compilers, just
as I don't think C++ would have a snowball's chance in hell of winning if
the current ISO draft was thrown in implementors' faces with an "implement
_this_" attitude.
probably forging a bad pun, I'd like to think of this as the incrementality
of standards editors, with stress on "mentality".
#<Erik 3028583669>
--
suppose we actually were immortal...
what is the opposite of living your life as if every day were your last?
From: Barry Margolin
Subject: Re: ISO on Common (was: ISO/IEC CD 13816 -- ISLisp)
Date:
Message-ID: <4bfknd$b8f@tools.bbnplanet.com>
In article <··········@info.epfl.ch>,
Fernando D. Mato Mira <········@lig.di.epfl.ch> wrote:
>What hurdles, if any, exist to implement ISO Lisp as a thin layer
>of macrology on top of Common Lisp?
I believe that Kent Pitman was acting as X3J13's representative to the ISO
Lisp committee during the time that ISLisp was being finalized. One of his
goals in this role was to make sure that ISLisp would be compatible enough
with Common Lisp to allow such a package to be written. We also made some
small, last-minute changes to Common Lisp to enable this (sorry, I can't
think of any specific ones right now).
The layer of macrology would probably be relatively "thick", not thin, but
it should be doable.
--
Barry Margolin
BBN PlaNET Corporation, Cambridge, MA
······@bbnplanet.com
Phone (617) 873-3126 - Fax (617) 873-6351
One ISO-inspired addition that I remember was DEFINE-SYMBOL-MACRO. This
makes it possible, for example, to implement an ISLisp global variable as
a Common Lisp reader-writer function pair.
- Larry Mayka
Subject: Re: ISO on Common (was: ISO/IEC CD 13816 -- ISLisp)
From: ······@tools.bbnplanet.com (Barry Margolin)
Date: 22 Dec 1995 20:06:53 -0500
Message-ID: <··········@tools.bbnplanet.com>
In article <··········@info.epfl.ch>,
Fernando D. Mato Mira <········@lig.di.epfl.ch> wrote:
>What hurdles, if any, exist to implement ISO Lisp as a thin layer
>of macrology on top of Common Lisp?
I believe that Kent Pitman was acting as X3J13's representative to the
ISO
Lisp committee during the time that ISLisp was being finalized. One of
his
goals in this role was to make sure that ISLisp would be compatible
enough
with Common Lisp to allow such a package to be written. We also made
some
small, last-minute changes to Common Lisp to enable this (sorry, I
can't
think of any specific ones right now).
I seem to remember Kent mentioning on the last day of of LUV-95 that he
and
some others have played around with a partial implementation of ISLisp
within
CL. Is anybody listening that can comment? Kent?
The layer of macrology would probably be relatively "thick", not thin,
but
it should be doable.
--
Barry Margolin
BBN PlaNET Corporation, Cambridge, MA
······@bbnplanet.com
Phone (617) 873-3126 - Fax (617) 873-6351