Re: Var-free programming (slightly off-topic)

[Shriram Krishnamurthi <address@hidden>]

Dan,

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
available from

  http://www.cs.rice.edu/CS/PLT/Publications/

- 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

  http://www.htus.org/Book/Staging/how-to-use-modules/

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
your state.

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.

Shriram