[r6rs-discuss] [Formal] Eliminate compound library names

From: MichaelL_at_frogware.com <MichaelL>
Date: Tue Nov 14 00:01:05 2006

> Suppose developer A sends developer B a single file with 50 libraries
> in it, expressed as 50 separate S-expressions. (Developer A has
> tested their code by loading that single file into their scheme
> system, along with some auxiliary file acting as a script.)
> Developer B receives the file, but since she is using a different
> Scheme system, she has to pull out the 50 distinct libraries and put
> each into its own file, potentially in some subdirectory path that
> might correspond to the compound name, because that is what developer
> B's particular library implementation requires. Developer B, after
> doing this extraction, fires up their scheme system, runs the script,
> and successfully uses code from the installed libraries.
>
> To me, the above scenario describes the delivery of portable code.
>
> Other people might assert that the above scenario does not
> describe the delivery of portable code, because Developer B had to
> post-process the source file to pull out the library forms.
>
> Am I right in thinking that you and I have different visions of what
> "portability" means?

Yes.

In your example A sent a file to B. What if instead we suppose that A and
B are working collaboratively and using version control? For example,
suppose that they're working on SSAX (a Scheme-based XML parser) and that
the project is hosted on SourceForge. The transformation you're talking
about would have to be done by one of the developers each time they
checked code in and out. I have to think that such transformations would
make the development process rather confusing. What if, for example, there
are conflicts that have to be resolved? B might have to try to resolve the
conflict in A's file format (since that's what's checked in) and then
re-split the file to test the resolution using B's compiler.

Now let's suppose that only A is working on SSAX, but A is making an
effort to make the library portable across a variety of Scheme
implementations. If A really has to transform code to test the library in
each Scheme, I rather suspect that A's enthusiasm for portability will
quickly peter out.

Finally, your example suggests the transformation might be easily
automatable. I'm not sure I agree, because I think some of the library
issues go beyond whether compound names map to a file hierarchy. For
example, you seem to assume that the import clause may trigger the loading
of a library. I am pretty sure that at least some Scheme implementors
don't make that assumption. So in that case how does the library get
loaded? Perhaps using something like "load" or "include"--and I've written
elsewhere how implementations can make reasonable but different
assumptions even there.

I think there might be more Scheme developers out there than it first
appears, but I think their efforts are spread across many Scheme
implementations. I think it would be good for everyone if R6RS made it
easier to combine efforts and share code. Not that it's impossible now; it
isn't, and there *are* libraries (like SSAX and SLIB) that work across
implementations. But I see the possibility that, for example,
under-specified compound library names will make things worse than they
are now. Which is to say: less portable.

> Don't get me wrong; I will not complain if R6RS ends up defining a
> much stricter protocol for delivery of libraries. But I also believe
> that software component delivery and linking is an open research
> area, and therefore we should avoid tying ourselves to any particular
> notion of how libraries map to files.

I'm not sure I agree. The fact that R6RS specifies something doesn't close
it to research. For example, syntax-rules was in R5RS and now we have
syntax-case.

In any event, and somewhat ironically, I am really more concerned that
R6RS implements libraries as a big black box. I think there's another
approach, one that would open some of the mechanisms so that (for example)
code that finds a library from some kind of identifier or name could be
written in a portable way. What I had in mind is similar to what Will just
wrote about records: perhaps R6RS should focus on exposing the lower level
mechanisms and leave out the higher-level syntactic wrapper. That would
allow wrappers to be written in a portable way, leaving open exactly the
kind of experimentation you're talking about.
Received on Tue Nov 14 2006 - 00:00:43 UTC