Bertrand> I do think that there is more to the melting ice (in
Bertrand> particular the connection between compiled and interpreted
Bertrand> code, and the ability to treat very large software systems)
Bertrand> than what had been done before, but this is a conjecture,
Bertrand> not a certainty.
Most Lisp systems allow interpreted and compiled code to be mixed
freely (i.e. a compiled function can call an interpreted one and vice
versa).
And because, in Lisp, most references to functions (and classes, etc.)
pass through an additional name->address mapping, it is possible to
simply reload or recompile the definitions that have been changed.
Unfortunately these possibilities of compiled/interpreted code
intercalling and (mostly) free redefinition imply a certain run-time
overhead. That overhead could be compiled away before the application
is deployed, but this technology is somewhat underdeveloped for Lisp.
Compare this with the situation in other languages like C or C++,
where the technology to create compact and efficient applications has
existed for a long time, while the development environments have only
just started to come of age (compared to Lisp or Smalltalk).
This tells us that both "camps" could learn a lot from each other!
Bertrand> All questions of historical precedence aside, the only
Bertrand> certainty is that the Melting Ice Technology is present in
Bertrand> the ISE Eiffel 3 implementation and that it works.
--
Simon.
From: Jeff Dalton
Subject: Re: Melting Ice in ISE Eiffel (was: Re: C++...)
Date:
Message-ID: <Cn6s9v.Gvy@cogsci.ed.ac.uk>
In article <···················@liasg3.epfl.ch> ·····@lia.di.epfl.ch (Simon Leinen) writes:
>Bertrand> I do think that there is more to the melting ice (in
>Bertrand> particular the connection between compiled and interpreted
>Bertrand> code, and the ability to treat very large software systems)
>Bertrand> than what had been done before, but this is a conjecture,
>Bertrand> not a certainty.
>
>Most Lisp systems allow interpreted and compiled code to be mixed
>freely (i.e. a compiled function can call an interpreted one and vice
>versa).
>
>And because, in Lisp, most references to functions (and classes, etc.)
>pass through an additional name->address mapping, it is possible to
>simply reload or recompile the definitions that have been changed.
>
>Unfortunately these possibilities of compiled/interpreted code
>intercalling and (mostly) free redefinition imply a certain run-time
>overhead. That overhead could be compiled away before the application
>is deployed, but this technology is somewhat underdeveloped for Lisp.
I think the situation in Lisp is somewhat better than it may seem.
The additional name->address mapping can be pretty cheap, just
an indirection. (Think of a call via an address in a table.)
There are various ways to arrange this. Anyway, we're talking
about something like one extra memory reference.
Moreover, there are a number of cases where direct calls can
occur. (For instance, to local functions defined via LABELS.)
It's interesting to note that procedure calls in Lisp used to be
more efficient than in most other languages. This is because they
were very frequent in Lisp and so the effort was made to optimize
them. In other languages, procedure calls were often regarded
as inherently pretty expensive and as something to avoid.
(See Steele's paper on the expensive procedure call myth and
the Multics Emacs paper in the 1980 Lisp conference for some
more on these lines. Multics Emacs was written in Lisp even
though PL/1 was to Multics as C is to Unix in part because
every keystroke was going to be a procedure call and such calls
were too expensive in PL/1.)
Indeed, it was trivial to write Franz Lisp programs that outperformed
C on a VAX, because C always used the "calls" instruction while Franz
would use something less expensive for calls to functions declared
to be "localf".
-- jeff
In article <··········@cogsci.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
Indeed, it was trivial to write Franz Lisp programs that outperformed
C on a VAX, because C always used the "calls" instruction while Franz
would use something less expensive for calls to functions declared
to be "localf".
jsb, right? Or has my VAX assembler leaked completely through the
holes in my brain pan.
bruce