[racket-dev] using Racket to build an image-based Lisp: feasible?

Larceny (a Scheme) supports images.  I had another dance with them awhile
back playing around with Gilad Bracha's Newspeak.  I hear the Dart folks
have debated support for platform independent images of Dart programs to be
served out for executing in Chrome.  They'll probably do it.  They are
certainly experimenting with the idea.

The problem I hit with images was knowing the state of the state of the
image and ability to recreate that known state if necessary upon loss of an
image.

With Typed Racket, immutable structs etc. I really do focus on writing
pragmatically Functional code, in the sense of referential transparent
code.  As a result there is very little state to capture other
than exploratory interactions at the top level or within a namespace via
the REPL.  Those explorations I'm more than happy to throw away as I've
lost track of the mutating sequence of steps I've been binding in there
anyway.

How much value is there in creating an image of a purely functional
program?   How far from a persisted image is the persisted code?

Compare and contrast with an OO language like Smalltalk or Newspeak which
are encapsulating state and evolving that state.  Snapshotting the current
state of that evolving state in a persistent image has more utility there I
think, modulo, the mentioned issue of a perfect understanding of the
current state, and confidence in a 100% reproducability, back to that state.

With Git, for example, one has very granular state of source code evolution
and given a primarily purely Functional code base, the source code offers a
fairly close approximation of an image.

At the function/procedure definition level incremental compilation at the
REPL is a bit more of loss for me.  But I'm finding that is also lessening.
 These days (re)launching a REPL into a fresh namespace is almost immediate.


On Tue, Mar 5, 2013 at 1:39 PM, mikel evins <mevins at me.com> wrote:

>
> On Mar 5, 2013, at 12:12 PM, Eli Barzilay <eli at barzilay.org> wrote:
>
> > A few minutes ago, mikel evins wrote:
> >>
> >> On Mar 5, 2013, at 11:55 AM, Eli Barzilay <eli at barzilay.org> wrote:
> >>
> >>> An hour and a half ago, Matthias Felleisen wrote:
> >>>>
> >>>> I have empathy for your perspective, because I have worked with
> >>>> images and -- at the time -- found them useful.
> >>>
> >>> I think that *most* of Mikel's long post was about the advantages
> >>> of having a live REPL,
> >>
> >> Then I didn't express myself clearly enough. Sorry about that.
> >
> > So let me clarify a bit more (though this is obviously my very
> > subjective opinion)...  I loved doing the kind of live-REPL-based
> > debugging that you're talking about, but every once in a while things
> > would get messed up in a way that made it much easier to just restart
> > the whole thing.  I've also used images, but the main thing that
> > bothered me about them is that they're heavily oriented in the other
> > direction: instead of restarting the application from scratch where I
> > know that the code is only what's in the source, it encourages
> > continuous tweaking of the live REPL where you continue to tweak and
> > try to fix it to later dump a new image.
> >
> > Eventually, I concluded that images are a cute thing in theory, but in
> > practice they were too limited in the reduced ability to deal with the
> > source code.  Maybe Emacs is a good example of this: even though it's
> > image-based, developement happens on the source, with the image
> > feature being pushed to just another step in the compilation chain.
> >
> > (Disclaimer: the systems that I used with images were the common ones
> > where there's no support for editing the live source -- not the fancy
> > lisp machine or smalltalk things.)
>
> The problem you're describing is real, and is one of the prices paid for
> image-based development. It doesn't cancel out the advantages, but it's
> something you have to learn to deal with appropriately. One of the ways you
> deal with it is through process: we kept reference images and checkpoints,
> so that we could roll back troublesome changes. That wasn't burdensome
> precisely because saving and loading an image was so fast and easy.
>
> Another way you deal with it is to develop the kinds of tools you
> mentioned--tools that give you greater power to identify and change the
> things you want to change. Some of the tools that working programmers take
> for granted nowadays were invented in that context, and I think it's
> reasonable to expect that more of them will be, as long as we don't forget
> how to make and use image-based environments.
>
> I had to think some more about how my remarks might have led you to think
> I was talking about REPLs. Let me take another stab at it by mentioning
> things that REPLs don't provide.
>
> I don't in any way want to discount the value of a live REPL; it's
> indispensible. It's not what I was talking about, though.
>
> By itself, a live REPL doesn't grant me the power to preserve the
> incremental dynamic state of my work-in-progress with a single quick
> action, nor to equally quickly recover that state. When I have that power,
> I use it constantly.
>
> It doesn't make delivery of incremental release candidates as quick and
> simple as saving a word-processing document.
>
> It doesn't offer me a bog-simple, quick, and convenient way to preserve
> snapshots of my progress on a task, nor to provide snapshots I can use to
> reproduce *exactly*, and with all its dynamic details, a pathological state.
>
> It doesn't offer me a way to package a whole dynamic machine state to give
> to someone else, so that they can see what I see, nor an equally quick and
> simple way to illustrate proposed changes by making them directly in their
> intended context in a way that another person can see and interact with
> them immediately.
>
> It doesn't give me a way to checkpoint the space of changes and use the
> checkpoints to zero in on the change that introduced a bug.
>
> It doesn't give me a quick and simple way to roll back an unfortunate
> change, and without that ability, experimentation carries a higher cost.
> Maybe lowering the cost of experimentation seems a small advantage; it
> isn't.
>
> REPLs don't do any of these things, though they complement them nicely. If
> you have these abilities, they're better if you also have a REPL, and the
> reverse is also true.
>
> REPLs are a dime a dozen nowadays. Clojure has one. So do FORTH, erlang,
> Ruby, Python, the various flavors of ML, and Haskell. The REPLs in Lisp and
> Smalltalk systems are different. TO a much greater degree than in other
> systems, you can use them to incrementally build up state that provides a
> progressively closer approximation to what you're trying to build. An
> image-based Lisp or Smalltalk is better still, because you don't have to
> recapitulate the groundwork every time you start the REPL; instead, having
> achieved a congenial state, you can just save it, and then resume it later,
> just as easily.
>
> Naturally, you don't always want that. Sometimes a reference state, free
> of accumulated deltas, is what you want. Image-based systems don't in any
> way prevent you from having that. On the contrary, they make it easy to
> provide yourself with several different ones for different uses. You do, of
> course, have to realize that you're going to want that, and take
> appropriate steps to ensure that you have it when you want it. That's one
> of those things that comes with experience, or with good advice from an
> experienced colleague.
>
> But not having the capability to save and load an image provides no
> advantages. Anything you can do without that capability, you can do with
> it. The reverse is not true.
>
> --me
>
>
>
>
>
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130305/fbcda5ce/attachment-0001.html>