Re: Adding a New "primitive" Method.

[Paul Fernhout <pdfernhout@kurtz-fernhout.com>]

Matthew Flatt wrote:
> 
> I've long dreaded the day that someone wants to modify MrEd
> significantly. The MrEd-MzScheme glue is one of the oldest, trickiest,
> grossest parts of the system. It's long overdue for an overhaul, but we
> have a few other things to overhaul first.
> [Snip]
> Of course, if I did it over again, I'd turn MzScheme in a compentent
> scripting language before creating MrEd, instead of the other way
> around. Then there'd be no perl code in the build process.
> [snip]
> I'm gradually cleaning up the source code to make it readable, but
> currently I'm working in plt/src/mzscheme/src and the wxWindows code.
> It's a long-term project.
> 
> Meanwhile, I predict significant upheaval in the implementation of
> MzScheme and MrEd over the coming months. Nothing that will make MrEd
> easier to modify, though.

I certainly found the complete MrEd source intimidating after I
downloaded it. Mostly this is because if I picked DrScheme because I
liked Scheme, why would I want to muck about with massive amounts of
complex C code? (Not that I can't, it's just that I prefer not to.) It
was definitely a hesitation point in my thinking about using DrScheme
for commercial use (as I have to anticipate supporting it myself to be
on the safe side). It wouldn't have been as much of an issue if that
source was tracking the wxWindows standard release (2.0) as there would
be a large group of supporters presumably. Since the above will sound
critical, let me add I do think DrScheme succeeds at its purposes
(especially for education), and is well supported, and is a good choice
for many things, and wxWindows does seem to work well and looks
professional (and is picking up momentum).

Just a thought, but if you decide to make major changes you might want
to look at the Squeak architecture. In short, Squeak supports a few core
primitives (e.g. bitblit and putting a bitmap on the screen) which are
easy to port to various platforms (about 2000 lines of platform specific
code a while back) and then builds the rest of the GUI in Smalltalk. In
this case, all that GUI code could be written in Scheme. Ideally, these
few platform specific elements (bitblit, sound, networking, files, etc.
are loaded as plugins or foreign function calls. Historically, the
Symbolics Lisp machine was implemented more in this fashion (most
everything in ZetaLisp).

Then, borrowing another Squeak idea, if the source for MzScheme was
written in a subset of MzScheme with a translator to C (or whatever
target language -- assembler?), you would have a very sleek system for
maintainers and low level developers who wanted to code mostly in
Scheme. 

The result would probably outperform Squeak for some common operations
by a couple of powers of 2 (because of various Scheme compiling
efficiencies).

This process would be made more feasible if there was already Scheme
code for drawing and managing GUIs.

There are various drawbacks to this approach -- one is the perennial
native widgets vs. emulated widgets argument -- and wxWindows is a
smooth running system with quick response on several key platforms.
(Remember -- native widgets are still "emulated" by the OS -- the
difference is just that the OS support code is written in C or assembler
and may be more closely tied with low level drivers.) The Squeak
approach produces (almost) satisfactory GUIs now on a certain class of
machines (200Mhz+). I think ultimately the Squeak architecture style
will win out though (though maybe not till we're a another two or so
generations up the Moore's law curve -- so about three to five years,
and then even a little longer for the social lag). 

There are other drawbacks to the Squeak emulated widgets and monolithic
image approach. These have to do with overwhelming the developer with
extraneous code (the LearningWorks project addresses this somewhat) and
also making it easier for a novice developer to crash the system by
disrupting core GUI or development support code. However, if one builds
on the existing modularity of MzScheme, hopefully some of these pitfalls
can be avoided. One way to do this is by cleanly separating the code
that does the GUI display or debugging or supports development in some
other namespace or even process (i.e. remote debugging), so that it is
only modified if done intentionally.

The educational value to the Squeak-style emulated widgets approach for
a computer science curriculum is that it makes the system more
transparent to the beginning (non-C programmer) user. As has been
demonstrated in Squeak use at Georgia Tech by Mark Guzdial and others,
it is impressive and inspirational to students when they can get right
in there and draw a line over multiple windows for example. (This
transparency has other larger social implications as well, in terms of
potentially giving individuals more control over their environment.) 

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com