[plt-scheme] Re: Is R6RS useless for PLT?

On Nov 18, 2008, at 12:18 PM, Ernie Smith wrote:

> A helpful answer to his question would be to suggest a strategy
> to  keep control over the 'willy-nilly' and thus minimize
> risk and maximize recourse in the possible event of extinction.



I agree with the sentiment of your post.  Relying on a single
implementation with one or a handful of developers does pose
a risk.  There are many possible strategies:

1. Hope for the best: Stick with your implementation of choice
and hope that it outlives your project.  Given the momentum of
PLT, this may not be too bad an idea.  The situation is
radically different in (all?) other implementations that have
exactly one developer.

2. Expect the worst: Refrain from using any nonstandard
feature that your implementation provides.  If it's not in the
report it's not in your code.  This is extreme and
unrealistic.  It's equally unrealistic to expect that all of
one implementation's features will become standard.

3. Eat your cake and have it too: Isolate the parts of your
code that use implementation-specific extensions from the rest
of your code, and keep your main code base platform
independent.

Now the implementations (not the standard) of R6RS all provide
a uniform mechanism for you to take strategy 3---it's up to
you to utilize it.  All implementations allow you to restrict
your code to the standard features (if so you choose), and
they all allow you to incorporate common but nonstandard
features into your program without this 'willy-nilly' use of
such features.

This works by writing the majority of your code in the form of
R6RS libraries, and when it comes to common but nonstandard
features, you supply an implementation-specific compatibility
library for each implementation you intend to use.

For example, suppose your program uses "process" to run an
external shell command.  Now process, being nonstandard
feature comes with different flavors under the different
implementations.  Instead of depending on say PLT's process,
you provide a (process) library "process.mzscheme.sls" that
reexports mzscheme's process procedure.  Want to run your
program under Ikarus?  Provide a "process.ikarus.sls" file and
you're done.  Try to run it under Ypsilon?  It will complain
that it cannot find the (process) library and you know what to
do then.  Common features like process should eventually end
up being SRFIs so that you won't have to port them and write
compatibility libraries yourself, but until then, it's usually
a few lines per implementation depending on the feature.

This strategy works for most features and I've used it to port
large libraries (e.g., OpenGL, GLUT, etc.) from Ypsilon to
Ikarus (by providing an ypsilon compatibility library) and
I've seen people using it for even more ambitious situations
(e.g., a portable GTK over the pipe interface).  It's doable
and it's not that hard; it just takes some discipline.

Aziz,,,