From: Matthew Flatt <mflatt@cs.utah.edu>
To: plt-scheme@list.cs.brown.edu
Subject: [plt-scheme] reading "graphical" files without MrEd
Date: Fri, 19 Jan 2007 12:12:26 +0800

The new "wxme" collection in the SVN trunk supports reading the content
of "graphical" files in MzScheme (i.e., without MrEd). Graphical-format
files are generated when you use comment boxes or some other kind of
non-text syntax in DrScheme. Until now, graphical-format files were
readable only when using MrEd, which creates various problems.

The new library should work with all versions of the graphical file
format and for all of the popular forms of graphical syntax offered by
DrScheme. Search for "wxme" in Help Desk for information.

Implementors of new graphical syntax must cooperate with the "wxme"
collection to make the graphical syntax readable with MzScheme.
Currently, when you implement a new form of graphical syntax, you
should give it a name generated by

 (format "~s" ’(lib <str> ...))

MrEd recognizes this name format, and it can load the snip
implementation on demand when reading WXME files. To support reading
via MzScheme, though, start using names of the form

 (format "~s" ’((lib <str> ...)
                (lib <str> ...)))

MrEd will use the first module path, and "wxme" will use the second.
See the "wxme" documentation for details. The "wxme" collection has a
built-in mapping for various kinds of graphical syntax in DrScheme that
are historically popular, and you can add new compatibility mappings if
necessary.

Changing the name of your snip class means that old versions of MrEd
won’t be able to read files saved with the new version (since older
versions of MrEd won’t recognize the new name format).

The next version of MrEd will change the WXME format, anyway. We’ll
change the magic WXME string by adding a "#reader(\"read.ss\"\"wxme\")"
prefix. This prefix will allow MzScheme to do the right thing
automatically when you load a program that is saved in the graphical
file format --- at least as long as you stick to things like comment
boxes and XML boxes (in contrast to images) that are easily converted
to text.

MrEd’s default load handler will continue to detect the magic WXME
header and load WXME files into an editor% for reading. So, running a
program in MrEd will mostly work as before (e.g., take advantage of
graphical support).

A program running in MrEd could still end up going through the "wxme"
collection’s conversion. For example, a program might open a file with
`open-input-file’ and then apply `read’ or `read-syntax’ to the
resulting port. In that case, the program is not going through the load
handler, but the "#reader" prefix triggers the "wxme"-based conversion.
This will happen, in fact, when you use the "Create Executable" menu
item in DrScheme to create a stand-alone application from a module
whose source includes graphical elements. Maybe that’s bad, because you
meant to create a graphical application that uses MrEd; or maybe that’s
good, because you’re creating a MzScheme executable, or because it’s
consistent with what mzc (a MzScheme-based program) would do. In any
case, it’s certainly an improvement, since creating an executable with
graphical source doesn’t work at all as of version 369.5.

Overall, with the new layer of hooks and parsers, the right thing will
happen more often, but some combinations of operations and environments
will still produce surprising or inadequate results. No doubt there’s a
better solution that involves deep changes to the way that non-text
syntax is handled, and maybe we’ll get there eventually.

Matthew