[racket] need feedback on syntax-expanding/rewriting image-snips

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Tue Aug 9 16:58:51 EDT 2011

On Tue, Aug 9, 2011 at 3:57 PM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> Oh, I see. Thanks for clarifying.
> As best I understand it, then, you're adding the ability to have image
> (and other snip) constants in compiled code, something that elsewhere
> in the system we skirt around by just not compiling things (eg when
> building an executable if there is a file with an image constant in
> it, it just doesn't get compiled).
> I guess the Right Fix is to figure out some general-purpose mechanism
> for dealing with graphical syntax and do that, so that compiled
> bytecode

... oops, forgot to finish this sentence: so that compiled bytecode
can contain image constants (and generally there are constants other
than the well-known pairs, symbols, strings, etc).

> I don't see a way that is fundamentally better than what you're doing
> there, but one minor tweak is that you could turn the images into
> something like this
>  (make-an-image #"...image's bytes go here")
> instead of a url, where make-an-image builds the image from the bytes.
> But maybe you have some reason why urls work better, I'm not sure.
> Robby
> On Tue, Aug 9, 2011 at 3:48 PM, Danny Yoo <dyoo at cs.wpi.edu> wrote:
>> On Tue, Aug 9, 2011 at 3:50 PM, Robby Findler
>> <robby at eecs.northwestern.edu> wrote:
>>> I think you should be working with the wxme library, not with image
>>> snips directly. Did you investigate that?
>> Implicitly, that's being done for me.  I'm depending
>> read-accept-reader to do the right thing when I read wxme-encoded
>> source programs.  Trying to deal with the file as a raw wxme-encoded
>> file seems unnecessarily low-level, since I know that the source
>> program is readable with read-syntax.
>> zo-parse does not work on compiled-code values directly, nor does it
>> work when given the input port of the original source program.  It
>> only works when given an input port containing compiled bytecode.
>> That's why there is this extra, involved step where I compile to
>> bytecode, and then attempt to push that bytecode into a port.

Posted on the users mailing list.