Re: MzScheme Special Form -> Native Numerical Code?

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

Matthias Felleisen wrote:
> 
> Thanks for the pointer. I know Norman quite well and will discuss this with
> him. But in all honesty, I believe students see too many low-level details
> in currentc curricula, and not enough reasoning about values and operations,
> logical claims and invariants. The latter is far more important for software
> engineering in the end than the machine. -- Matthias

Matthias -

Small world!

I completely agree with your point about students seeing too many low
level details. I taught a couple of programming classes in C and Pascal
to college biology majors, and some large percentage really only made
the most progress when I was actually in the computer lab with them to
help them over syntax hurdles. As TeachScheme! points out, programming
should be part of a liberal arts education, and realistically that means
if students learn something about algorithms they are much better off
than knowing a specific arcane processor architecture or the twisted
syntax of one popular language. Given limited resources, TeachScheme!
and related efforts should focus on what they are doing now -- which is
fantastic.

Frankly, I just like the idea of generating native code under user
control from higher level languages, and saw your VM class as a possible
way to get that feature added to MzScheme for little work (on my side),
in a way that students might benefit from. :-) Too often class projects
are just throwaways -- I'd love to see more college students (especially
CS majors) making useful and distributable software packages as part of
their studies, seeing through a work from conception into distribution
and maintenance. 

By the way, your VM students might enjoy the open source 80X86 emulator
at: 
  http://www.plex86.org/info.phtml

I guess I am thinking about this issue of machien code generation from
several different points of view (beyond improving numerical
performance).

One is the point of view of what it would take to make Scheme the
dominant language in a CS curriculum (over C/C++). Granted, that is not
the TeachScheme! focus, and I'm not suggesting it should be. However,
from that point of view, if one could poke around into memory with the
ease of say Forth but with all the advantages of DrScheme, that means
some career oriented students can see greater long term value in
DrScheme as part of their experience as a programmer. This would then
add one more selling point to get DrScheme into another area of the
curriculum. In fact, it would make DrScheme a much better choice than
C++ for teaching low level things because one would likely have much
finer control over the code produced using Scheme translation on a
function by function basis, and so students could see the tighter
correspondance between a small algorithm they created (in a subset of
Scheme or a related little language) and machine code that executed that
algorithm. And it would seem that such features could be had for
relatively little effort. Actually, the more I poke around, the more it
appears this sort of effort has been done before in Scheme and Lisp in
several places (mostly commercial implementations though).

>From another point of view, once MzScheme is generating and manipulating
real machine code, it becomes possible to conceive of doing
meta-compiling, where the system is written in itself, and a VM is
generated by translation (cross-compiling as it were to bootstrap a new
system). I've worked with Forths (like eForth) that do this. This is an
interest of mine, because I like "transparent" systems that are easily
understandable (for ideological reasons, see Langdon Winner's book
"Autonomous Techology"), and for me, any system that depends on an
opaque box like a C compiler is not "transparent" to the degree I would
like.

Also, once MzScheme can run dynamically loaded machine code, I could
more easily extend the system under Windows. There is an issue with
using Windows DLLs in that all users of a DLL share the same global
variable space, and so a user runs two MrEd-type sessions using the same
DLL, there is a potential for conflict (if a global variable is say set
with a pointer to a VM). For what I've seen of doing MzScheme
extensions, it appears this may be a problem in the MzScheme case
(because a VM isn't passed in as a function parameter.) I don't believe
this is an issue under Unix or the Mac, which I think both load
extensions into the executeables address space.

-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