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

From: Felix <pfr6rs>
Date: Mon Nov 13 21:30:50 2006

On Nov 13, 2006, at 6:22 PM, MichaelL_at_frogware.com wrote:

> But back to your point.
>
> I agree that R6RS leaves the issue of mapping compound names to
> file names
> open. I agree that an implementation might try to create a mapping.
> Indeed, I said I thought that was a specific danger:
>
>> Of course, even worse is the prospect that some implementations might
>> actually decide to map compound names to files. That raises the
>> spectre
> of
>> portability issues since the mapping isn't specified and would
> potentially
>> differ from one implementation to the next.
>
> To reiterate: It's tempting to think that compound names have some
> additional meaning, but they don't--at least, not according to the
> spec.
> If they really have no meaning, we're making things more confusing
> and it
> isn't clear what we gain in return. (Indeed, there are some things we
> might lose.) But if we add meaning we're likely to introduce
> portability
> issues since that meaning won't be in the spec; each implementation
> will
> likely have its own unique approach. Since libraries exist in part to
> improve portability that would be rather ironic.

I think we have a problem in that we have not defined "portability",
so when you say that you are worried about portability issues, I am
not sure what issues you are envisioning.

I do not have a formal definition of portability available. But I do
have some use cases in mind; here is one that I think will be
contentious.

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 doesn't 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?

If we define a strong relationship between libraries and directories/
files (as Developer B might well wish, given the work in front of
them), then I agree with you that compound names may pose a problem.
But if that mapping is not in place, as is the case in my vision, and
we give implementations a lot of leeway in how they choose to
incorporate library support into their systems, then I think this
particular complaint about compound names is not relevant.

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.

-Felix

p.s. Just a reminder: life's not so bad for Developer B; she knows
that as an experienced Schemer, its just a matter of hacking up an
script that uses READ and WRITE to install the libraries
appropriately -- a task that would actually be easier with compound
names as currently described, rather than parsing tokens out of
identifiers... It might be reasonable to require that every Scheme
environment provide such a script as a standard piece of equipment.
Received on Mon Nov 13 2006 - 21:30:31 UTC