[plt-scheme] Re: PLT R6RS questions and answers

Hi Tom,

Tom Gordon <thomas.gordon at fokus.fraunhofer.de> writes:

> Here you've lost me.  Isn't code written specifically for
> PLT almost by definition not portable?  At least a
> significant manual effort is required to port the code.
> Are you suggesting it is no more difficult to port
> programs from the PLT dialect of scheme to (other) R6RS
> implementations than to port a programs written in R6RS,
> to the extent possible, from one R6RS implementation to
> another?  This hardly seems plausible to me.

Sorry, I was just trying to point something out and doing a
poor job of explaining.

If you write code for PLT, using idiomatic PLT code and
libraries, then you can develop a large variety of
applications (pretty much anything).  However, you need to
do some work (potentially substantial) to port it to other
implementations.

If you write code for R6RS, using only R6RS libraries, then
it will run on any of the R6RS implementations.  On the
other hand, you're somewhat limited in the type of
application you write - you can't use any graphics,
networking, processes, threads or FFI.

If you want to use any of those features in R6RS, you have
to hack it.  Basically, there's a little manual porting
effort to get it working in different implementations, and
then to distribute it you rely on some makefiles or such.

Now, R5RS is pretty much in the same situation as R6RS.  For
ease of porting, there are two major differences:

  1) The module system that let's you glue things together.
  What this means in practice is that instead of the
  makefile just renaming files, it will need to do some
  simple preprocessing of the files.  There are easily a
  dozen projects that do this, and once you've chosen a
  preprocessor utility the daily coding doesn't change.

  2) Unavailability of some non-portably standardized R6RS
  features.  Mostly this is just binary I/O and file-system
  utilities.  Everything else can be implemented in R5RS.
  In practice you just need to abstract and implement these
  libraries once for each implementation you want to
  support.

And if you target R5RS, you suddenly have a much wider range
of implementations, many of which are more mature and stable
and have larger communities than the R6RS implementations.

Another way of looking at it is to consider a graph that
compares the number of features (or expressivity) versus the
ease of porting to other implementations, it may look like:

  ease of
  portability
    |
    | 5  6
    |
    |          6+
    |
    |          5+
    |
    |                    P
    |
    +------------------------- features

        5 = R5RS
        6 = R6RS
        5+ = R5RS + preprocessor
        6+ = R6RS + makefiles/preprocessor
        P = PLT

In words, compared to a full implementation like PLT, both
R5RS and R6RS have _tiny_ feature sets, and with some extra
porting work (easier for R6RS) they can both approach PLT's
features.

This is obviously a rough graph and the distances are
debatable - it's my own view of things skewed quite heavily
by the experience I've had writing portable R5RS libraries.
But it does raise the question of whether R6RS is really the
best target for portability.  Keep in mind, all of the third
party libraries you used in your project were originally
written for R5RS.

On the other hand, by their very nature R6RS implementers
are more willing to compromise, and if you're hoping for
improved portability in the future you should probably stick
with that group.  But if they're just going to get defensive
and ignore people who point out areas where their
portability is lacking, maybe that's a dead-end :P

-- 
Alex