20 minutes ago, mikel evins wrote:
>
> 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.
Aha -- in that case, it seems that your image-based workflow is not
much different from working with just the sources *and* the (byte-)
compiled files that go with them, right?
There are some technical differences like one big file instead of a
bunch of them, and the fact that instead of invoking an external tool
you're doing the "compilation" inside the environment and it becomes
part of the next dump. These obviously make it more convenient than
what I'm talking about -- but at the highlevel it looks similar.
Assuming that, the disadvanate that I see is in the disconnection
between the images and the sources: sure you have both, but what if
during my interactions I've somehow managed to get something work
really well "by mistake" -- I can see myself sitting at the computer a
month later being infinitely puzzeled with "how did I get *that* to
work"... So if I had worked with images, I would probably end up
starting from the plain sources very often since I'd be worried about
work that gets lost this way.
> If you aren't interested in images, or don't like them, don't use
> them. I'm not here to convert anybody. [...]
BTW, I'm not arguing against it -- I have reasons to dislike "proper"
development happening with them. But what you're describing is not
forcing that -- and I wonder what is it exactly that makes this
particular feature so great. (When I worked with images, I used them
only as a distribution tool -- I didn't have experience with them for
actual development with other people, so the target audience would be
people who just run it.)
> 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.
Well, it would be nice to know how exactly this would look like. So
far, I think that it's roughly a way to dump the current state as a
kind of zo file -- extended with the ability to serialize more values,
and extended to represent a whole environment rather than a single
module or a single piece of data.
Note that clarifying that this is more like zo files was important,
since it clarifies that the "dump" doesn't have to be a straight
*memory* dump. Assuming this, I think that you can start with
dumping the current namespace as a zo file -- something like:
(define (dump-image file)
(call-with-output-file file
(λ(o) (s-exp->fasl (current-namespace) o))))
(define (load-image file)
(current-namespace (call-with-input-file "i" fasl->s-exp)))
This is of course far from working... The first problem is that a
namespace cannot be written this way. So there would be some scanner
that turns it into something that can, maybe adding some
representation layer on top of plain values. Making it work for
everything else (including required modules etc) that you can reach
from the namespace is probably "the only thing" that is needed...
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
