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

From: mikel evins (mevins at me.com)
Date: Wed Mar 6 11:54:27 EST 2013

On Mar 6, 2013, at 8:23 AM, Marijn <hkBst at gentoo.org> wrote:

> Hash: SHA1
> Dear Mikel,
> On 06-03-13 04:05, mikel evins wrote:
>> On Mar 5, 2013, at 12:56 PM, Eli Barzilay <eli at barzilay.org>
>> wrote:
>>> But looking at it more deeply I certainly lose something -- I
>>> lose the ability to use source code for development,
>> Come again? How does that happen? It has certainly never happened
>> to me.
>>> which could be a real problem for me if I'm working on some code 
>>> with someone remote and all we have to communicate are binary 
>>> images.
>> Well, sure, if I were suddenly somehow denied access to sources
>> and made to communicate with colleagues only through binary images,
>> that would be a bad thing, but I'm not losing any sleep over the 
>> possibility. Matter of fact, it never occurred to me before this 
>> moment that it could ever be a possibility.
> So how exactly does source code enter into this way of working where
> you type code at the REPL and save and load images? Is there a
> function that translates images to source code? Otherwise, how do you
> prevent losing your code? From source it is easy to get to an image,
> right? So what advantage is there to using images over source code for
> saving, loading and exchange? Or is what you're describing also
> possible using source code instead of images and then looks something
> like the ideas of Bret Victor (http://worrydream.com)?

Rather than answer your questions directly, it seems much easier and more apropos to address the underlying assumption that images and source files are somehow mutually exclusive. They're not. Adding the ability to save and load images does not subtract the ability to work with source files. I don't know why people seem to think that.

Maybe it's because the Smalltalk guys sort of absorbed the filesystem into their images. The fact that it's *possible* to do that doesn't in any way imply that it's *necessary*. I worked with image-based systems daily for years and the effect on my source files was nothing at all, except that maybe having images made it easier to write more working sources faster.

Even if you do choose to subsume the filesystem into the image the way the Smalltalk guys did, that still doesn't interfere with your ability to work with source files. Smalltalk guys still build their VMs from plain, ordinary source files. They still have fileIn and fileOut for working with source files from within their images. But, more to the point, there's no reason to subsume the filesystem into the image unless that's what you want to do.

If you aren't interested in images, or don't like them, don't use them. I'm not here to convert anybody. I just wanted a sense of how hard it would be to satisfy some project requirements. I mentioned in passing that I think the gradual disappearance of image-based systems is a significant cultural loss, and I still think that. C'est la vie.

Matthew and Matthias seem to be saying they think platform-independent images are probably doable; that's good enough for me, for now. If it turns out they're wrong, well, I can work around that. There are other options. It'll grow back.


Posted on the dev mailing list.