[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Var-free programming (slightly off-topic)
I think the connection is only tenuous. Many of the problems with
upgrading would persist in the face of linearity.
Mark Miller draws a useful distinction between different kinds of
upgrading. My colleagues and I have been studying these problems in
some depth for several years now; I think those of you seriously
interested in this problem would want to read some of our papers.
These papers all deal with the static forms of upgrading. They are
- ECOOP 98 Krishnamurthi, Felleisen and Friedman
Synthesizing Object-Oriented and Functional Design to Promote Re-Use
provides background, and explains how the nature of the language
plays a role.
- ICFP 98 Findler and Flatt
Modular Object-Oriented Programming with Units and Mixins
follows up to show how the right design of language features is
critical for accomplishing extensibility seamlessly.
- FSE 98 Krishnamurthi and Felleisen
Toward a Formal Theory of Extensible Software
also follows up, with a little more theory, and provides the same
pattern as the previous paper, but hidden in the details.
- ICFP 99 Flatt, Findler, Krishnamurthi and Felleisen
Programming Languages as Operating Systems (or, Revenge of the Son of
the Lisp Machine)
discusses the run-time support necessary to make this work well.
In addition, PLT Scheme's module system now offers very sophisticated
support for macros also. See
Because we have so much work on static upgrading, the PLT group at
Brown University has been studying the upgrading tasks that are per
force dynamic. We've written two papers, currently in review.
David Reiss, Greg Cooper and I have build a prototype extension of the
Kaffe JVM with efficient support for dynamic upgrading. I agree that
"A live program consists of a tremendous amount of state", and this
contradicts a "stop-and-upgrade" policy. Our JVM preserves
performance without sacrificing efficiency by implementing a lazy
upgrade policy. You don't need to specially annotate your code, and
upgrading is not linked solely to debugging.
Building on that, Paul Graunke, David Reiss, Greg Cooper and I built a
toy Java programming environment that exploits our JVM. In the
environment, you can make small changes to your code and click
"Upgrade", which means you don't need to reconstruct the state of your
running program just to use the new code. Because upgrading is lazy,
the system-wide upgrade process is virtually instantaneous --
individual objects upgrade as they go. This seems to be what Miller
calls "upgrade for prototyping" -- and you don't need to throw away
Relating this back to Lightweight Languages: in the early days of our
JVM, we needed a way to rapidly test its behavior. Coding in Java is
painful. Then David Reiss had a neat insight. He found out about
Skij (http://alphaworks.ibm.com/tech/Skij), one of the Scheme's
written in Java. As the Skij page points out, "Skij can be easily
grafted onto an existing Java program to serve as a debugging
interface to application objects." So David did just that -- he used
Skij to drive the execution and upgrading of the VM. This gave him an
object inspector, etc, for free. Whereas sticking to Java would have
made the whole process painful (and might, consequently, have made us
test the VM a lot less!), David was on his way in minutes.
Lightweight languages rule.