R6RS libraries
Peter Keller
Is it understood that libraries written with R6RS library semantics are
to be shared as source codes between different R6RS implementations? If
I understand it correctly, there is no such thing as a scheme ABI for
pre-compiled libraries right? So a library compiled with one R6RS
implementation cannot be linked with codes from a different R6RS
implementation, correct?
Thank you.
-pete
William D Clinger
> Is it understood that libraries written with R6RS library semantics are
> to be shared as source codes between different R6RS implementations?
I think that was the intention, but the R6RS failed
to specify any portable means by which a program
could define its own libraries, so you have to rely
on implementation-specific behavior even to use the
source code in more than one implementation.
> If
> I understand it correctly, there is no such thing as a scheme ABI for
> pre-compiled libraries right?
Right.
> So a library compiled with one R6RS
> implementation cannot be linked with codes from a different R6RS
> implementation, correct?
Right.
Will
Peter Keller
> I think that was the intention, but the R6RS failed
> to specify any portable means by which a program
> could define its own libraries, so you have to rely
> on implementation-specific behavior even to use the
> source code in more than one implementation.
Could I have a small example of how such implementation specific behaviour
arises in writing an R6RS library?
I'm very interested because I strive to write the most portable code
possible when I write scheme. I understood how to do this with R5RS,
but R6RS is a bit different, so I figured I'd ask for advice.
Thank you.
-pete
Grant Rettke
on the PLT discussion list: Filipe, I think, in particular.
leppie
The discussion is about precompiled libraries.
Michael Sperber
William D Clinger <cesu...@yahoo.com> writes:
> Peter Keller wrote:
>> Is it understood that libraries written with R6RS library semantics are
>> to be shared as source codes between different R6RS implementations?
>
> I think that was the intention, but the R6RS failed
> to specify any portable means by which a program
> could define its own libraries, so you have to rely
> on implementation-specific behavior even to use the
> source code in more than one implementation.
I don't see how programs enter the poster's question. The R6RS does
provide a non-normative recommendation for implementations, that allows
libraries to be distributed portably among implementations that follow
the recommendation:
http://www.r6rs.org/final/html/r6rs-app/r6rs-app-Z-H-7.html#node_chap_E
That page also provides a similar recommendation for program source
code. The fact that the recommendation allows an arbitrary number of
libraries to be shipped in a single contiguous piece of text, but not a
program and libraries in the same contiguous piece of text, was
understood by the editors when they considered different proposals.
Data on this can be found under "5. script syntax" here:
http://www.r6rs.org/r6rs-editors/2006-August/001643.html
Proposal #3 on the table then would have allowed distributing libraries
in the same contiguous piece of text---this aspect was part of the
discussion. Ultimately, it wasn't deemed important enough. Possibly,
the general assumption was that, if you could ship one piece of UTF-8
text to somebody, you could also ship two.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
William D Clinger
> Could I have a small example of how such implementation specific behaviour
> arises in writing an R6RS library?
I think Michael Sperber may regard "writing" as an
activity that has nothing to do with "storing". He
cited a non-binding appendix to the R6RS, which says [1]:
Implementations may take radically different
approaches to storing source code for libraries,
among them: files in the file system where each file
contains an arbitrary number of library forms, files
in the file system where each file contains exactly
one library form, records in a database, and data
structures in memory.
For example, Larceny provides five Larceny-specific
mechanisms that non-portable R6RS programs can use to
import or to define libraries [2]. Ikarus supports
only two of those five. Other implementations of the
R6RS, if and when they exist, may support none of the
five.
Michael Sperber wrote:
> I don't see how programs enter the poster's question.
In my judgment, the original poster was concerned with
the execution of libraries, and would not be satisfied
with writing libraries that cannot be executed.
Although libraries can be written without consideration
of programs, the R6RS specifies no way to execute the
code of a library that does not also involve a top-level
program (or Scheme script, if you want to count the
non-binding appendixes as part of the R6RS).
Will
[1] http://www.r6rs.org/final/html/r6rs-app/r6rs-app-Z-H-7.html#node_chap_E
[2] http://larceny.ccs.neu.edu/doc/user-manual.chunked/ar01s05.html
Peter Keller
> the execution of libraries, and would not be satisfied
> with writing libraries that cannot be executed.
>
> Although libraries can be written without consideration
> of programs, the R6RS specifies no way to execute the
> code of a library that does not also involve a top-level
> program (or Scheme script, if you want to count the
> non-binding appendixes as part of the R6RS).
My exact concerns are that if I write a large R6RS library, must all of
it live in one text file or not, and, if I restrict my implementation
to strict R6RS, can I use that library without change with other R6RS
implementations of Scheme.
If the fact is that a library may or may not be able to be spread across
multiple files depending upon the implementation, then the answer to my
question is "the library exists in one large text file".
If I use a strict R6RS implementation in my library, but I find I still
need to have implementation specific code in there when I want to use
the library in different R6RS implementations of Scheme (say Ikarus or
Larceny), then by what conventional mechanism is this implementation
specific code written?
Thank you.
-pete
William D Clinger
> My exact concerns are that if I write a large R6RS library, must all of
> it live in one text file or not,
That is implementation-dependent. Some implementations
may require the entire library to reside within a single
text file. Others may not require that.
Larceny does not allow a library to be split between two
or more files, and I don't think Ikarus does either.
Under some conditions, Larceny allows multiple libraries
to reside within a single file. I don't know whether
Ikarus allows that.
> and, if I restrict my implementation
> to strict R6RS, can I use that library without change with other R6RS
> implementations of Scheme.
You would have some hope of using that library without
change in other implementations of the R6RS, but there
is no guarantee. Some implementations might require you
to put all of your libraries into a single text file, and
might constrain the order in which the libraries appear
within that file. Other implementations might forbid you
to put all of your libraries into a single text file, and
might constrain the names of your library files. Still
other implementations might forbid the use of text files
altogether, insisting (for example) that you keep all of
your source code in some proprietary format.
> If I use a strict R6RS implementation in my library, but I find I still
> need to have implementation specific code in there when I want to use
> the library in different R6RS implementations of Scheme (say Ikarus or
> Larceny), then by what conventional mechanism is this implementation
> specific code written?
There is no conventional mechanism. All such mechanisms
are implementation-dependent.
Larceny, for example, allows you to import any of its
standard procedures using a "primitives" clause, e.g.
(import (rnrs)
(primitives system current-directory))
imports the Larceny-specific procedures named system
and current-directory.
That doesn't work in Ikarus. Similarly, there are
Ikarus-specific extensions that don't work in Larceny.
Obviously you are going to have to configure your code
separately for every implementation of the R6RS. Your
best bet, I think, is to write a separate configuration
script for every implementation you want to use. That
isn't so bad right now, because there are only two
R6RS-compatible implementations; perhaps we should hope
the number of such implementations will remain small.
Will
Andrew Reilly
> Obviously you are going to have to configure your code separately for
> every implementation of the R6RS. Your best bet, I think, is to write a
> separate configuration script for every implementation you want to use.
I got the impression, from the appendix link that Michael Sperber posted,
that the standard (or at least that non-binding appendix) anticipates
such a configuration script being part of each implementation, and that
it would normally be run on any received library in order to make that
library available to the programs that might subsequently use it. Of
course, that doesn't help if there's no standard for the form of the
received libraries, I suppose.
Cheers,
--
Andrew
Andrew Reilly
> The discussion is about precompiled libraries.
If there are issues regarding the portability of libraries in source
form, don't you think that discussing portability in other forms is
getting a bit ahead of the game?
--
Andrew
Michael Sperber
Andrew Reilly <andrew-...@areilly.bpc-users.org> writes:
> On Sat, 24 May 2008 13:44:43 -0700, William D Clinger wrote:
>
>> Obviously you are going to have to configure your code separately for
>> every implementation of the R6RS. Your best bet, I think, is to write a
>> separate configuration script for every implementation you want to use.
>
> I got the impression, from the appendix link that Michael Sperber posted,
> that the standard (or at least that non-binding appendix) anticipates
> such a configuration script being part of each implementation, and that
> it would normally be run on any received library in order to make that
> library available to the programs that might subsequently use it.
That is exactly correct. There was an elaborate appendix in earlier
drafts of the R6RS on how libraries are stored by an implementation.
You can see it here:
http://www.r6rs.org/document/app-html-5.96/r6rs-app-Z-H-10.html#node_chap_H
However, it was pretty complicated, and would not have been universally
applicable, which is why the (quite conscious) decision was made to
remove it. There's a paragraph on the issue on the page I cited:
http://www.r6rs.org/final/html/r6rs-app/r6rs-app-Z-H-7.html#node_chap_E
"Implementations may take radically different approaches to storing
source code for libraries, among them: files in the file system where
each file contains an arbitrary number of library forms, files in the
file system where each file contains exactly one library form, records
in a database, and data structures in memory."
I personally believe the crucial portability issue with moving libraries
from one implementation to another isn't how libraries are stored, but
rather how they are communicated.
Andrew Reilly
> I personally believe the crucial portability issue with moving libraries
> from one implementation to another isn't how libraries are stored, but
> rather how they are communicated.
Isn't communication of computer files rather trivial? I would have
thought that the important part was the specification of the form of the
text of the library. Is that not well defined, now?
Cheers,
--
Andrew
Grant Rettke
> I personally believe the crucial portability issue with moving libraries
> from one implementation to another isn't how libraries are stored, but
> rather how they are communicated.
Exactly. I had been under the impression that the goal was portability
of libraries.
For example, SRFI-1 might be implemented once and shared across
different R6RS distributions.
Was that ever the goal? Did it turn out that way?
andreu...@yahoo.com
I don't want to presume to speak for him, but I think the form of the
text may have been indeed what Mike Sperber meant by "communicated".
And yes, I believe that whether the form of a particular text
is portable is mostly well-defined, except maybe for
a couple of details involving macro phases.
Andre
Andre
Michael Sperber
Andrew Reilly <andrew-...@areilly.bpc-users.org> writes:
> On Mon, 26 May 2008 08:33:07 +0200, Michael Sperber wrote:
>
>> I personally believe the crucial portability issue with moving libraries
>> from one implementation to another isn't how libraries are stored, but
>> rather how they are communicated.
>
> Isn't communication of computer files rather trivial?
Of text files? Anything but (sadly), which is why the appendix
specifies encoding and normalization. Moreover, the contentious part is
packing several conceptual entities (the libraries) into a single piece
of contiguous text, which requires that the entities be somehow
delimited.
> I would have thought that the important part was the specification of
> the form of the text of the library. Is that not well defined, now?
Of course it is well-defined.
Michael Sperber
Grant Rettke <gre...@gmail.com> writes:
Yes, that was a goal, and R6RS turned out that way for many SRFIs. See
the draft of SRFI 97 for a discussion and a list:
http://srfi.schemers.org/srfi-97/
Derick Eddington
> My exact concerns are that if I write a large R6RS library, must all of
> it live in one text file or not
You can split a large library up into multiple sub libraries. So for
the (foo) library you can make (foo base), (foo helpers), etc.; the
(foo) library imports its (foo ---) and can re-export some or all of
their exports. So you'll have foo.sls, foo/base.sls, and foo/
helpers.sls, etc.
> if I restrict my implementation
> to strict R6RS, can I use that library without change with other R6RS
> implementations of Scheme.
I have successfully been using my R6RS programs/libraries [4], using
the same exact directories/files without change, on both Ikarus and
PLT Scheme (the newest development versions) and to some extent on
Larceny (to the same extent soon, I think, more below). Ikarus, PLT
Scheme, and Larceny all support library name to file name resolution
of (foo) -> SEARCH_DIR/foo.sls and (foo bar baz) -> SEARCH_DIR/foo/bar/
baz.sls . To have the same library file(s) work across these
implementations, you must structure your directories so they match the
leading parts of the libraries' names and end the libraries' file
names with .sls . PLT Scheme requires that every library file begin
with #!r6rs (which also has meaning to other implementations, but not
to the same extent and is not necessary for other implementations).
The implementation needs to be told what directories it should search
when trying to find a library's file -- Ikarus uses the environment
variable IKARUS_LIBRARY_PATH; PLT Scheme uses its "collects"
directories, I just symlink the directories into my $HOME/.plt-scheme/
3.99.0.25/collects/ directory (use the appropriate version directory);
Larceny uses its -path command line switch (you could make a shell
alias/function/script for larceny so you don't always have to tell it -
r6rs -path).
> If I use a strict R6RS implementation in my library, but I find I still
> need to have implementation specific code in there when I want to use
> the library in different R6RS implementations of Scheme (say Ikarus or
> Larceny), then by what conventional mechanism is this implementation
> specific code written?
There is an existing convention for this. Ikarus and PLT Scheme
currently support it [1] [2], and Larceny 0.97 plans to [3]. See [1]
and [2] for more about it, but briefly, a (foo) library imports its
(foo compat) sub library and depending on the implementation the foo/
compat.ikarus.sls or foo/compat.mzscheme.sls file is chosen over a
possible default foo/compat.sls and any other implementations' foo/
compat.IMPL.sls are ignored, and it's your responsibility to
understand what implementation-specific functionality can be used
semantically equivalently or can be wrapped in the .IMPL.sls file to
be.
[2] http://list.cs.brown.edu/pipermail/plt-scheme/2008-April/024133.html
[3] http://larceny.ccs.neu.edu/larceny-trac/ticket/517
[4] https://code.launchpad.net/~derick-eddington/ikarus-libraries/xitomatl
--
: Derick
----------------------------------------------------------------
William D Clinger
> ....Moreover, the contentious part is
> packing several conceptual entities (the libraries) into a single piece
> of contiguous text, which requires that the entities be somehow
> delimited.
You're telling us the R6RS editors failed to
notice that libraries are delimited by their
opening and closing parentheses?
Will
Michael Sperber
William D Clinger <cesu...@yahoo.com> writes:
No, quite the oppposite. They also didn't fail to notice that the same
isn't true of programs. I cited a link to the relevant phone-conference
minutes earlier in this thread.
bunn...@gmail.com
Ahem... Weren't you a member of the R6RS editors yourself?
(I don't quite understand were you stand, Will. From various
remarks on this newsgroup it makes the impression (at least to me)
that you are trying to distance yourself from R6RS, even though
you have been a R6RS editor and doubtlessly are partially
repsonsible for this enourmous pile of rubbish)
cheers,
felix
leppie
wrote:
> (I don't quite understand were you stand, Will. From various
> remarks on this newsgroup it makes the impression (at least to me)
> that you are trying to distance yourself from R6RS, even though
> you have been a R6RS editor and doubtlessly are partially
> repsonsible for this enourmous pile of rubbish)
>
> cheers,
> felix
He was/is an editor of the R5RS.
samth
This is not correct. The current version of PLT Scheme, although it
has not yet had a stable release, supports the R6RS. To download it,
see http://pre.plt-scheme.org .
Sam TH
Peter Keller
It is not my intention to cause some sort of flamewar like it had been
in the past concerning R6RS. If I want that, I'll start a thread called
"R6RS Flame: Moths Wanted".
I'm just looking for specific clarification on a couple of things. Nothing
more.
-pete
William D Clinger
> Ahem... Weren't you a member of the R6RS editors yourself?
Guilty. I was the fourth editor to resign.
> (I don't quite understand were you stand, Will. From various
> remarks on this newsgroup it makes the impression (at least to me)
> that you are trying to distance yourself from R6RS, even though
> you have been a R6RS editor and doubtlessly are partially
> repsonsible for this enourmous pile of rubbish)
You and I both voted against ratification of the R6RS.
Both of us gave reasons, as was required of all those
who voted against (but not those who voted in favor).
Those statements remain online at
http://www.r6rs.org/ratification/results.html
Of the eight who served as editors, only three
voted to ratify the R6RS. Two voted against,
and three abstained.
There is no doubt but that I am partially responsible
for the rubbish. On the other hand, I am not at all
responsible for changes made after my resignation.
Concerning one of those changes, which has been central
to this very thread, I had told the other editors (in
a telephone conversation like the one cited by Mike
Sperber) that we should be taken out and shot if we
were to do what the editors ultimately did.
Will
Derick Eddington
wrote:
> PLT Scheme ... [supports] library name to file name resolution
> of (foo) -> SEARCH_DIR/foo.sls
Correction:
PLT Scheme resolves (foo) to SEARCH_DIR/foo/main.sls (the library is
still named (foo) in that file). So, you can not use the same file
name and directory structure for a library with only one component in
its name across PLT Scheme and Ikarus and Larceny. I don't think this
will be a problem, because in order to avoid namespace clashes,
libraries should be named under a top-level namespace unique to the
entity who made them, i.e. (acme foo) or (acme foo bar) and (acme)
wouldn't make sense, and this will result in directory structures and
file names which will all work across PLT Scheme and the others. If
you really want to have a single component name which works with PLT
Scheme and the others, you can symlink SEARCH_DIR/foo/main.sls to/from
SEARCH_DIR/foo.sls
--
: Derick
----------------------------------------------------------------
bunn...@gmail.com
> Hold on here.
>
> It is not my intention to cause some sort of flamewar like it had been
> in the past concerning R6RS. If I want that, I'll start a thread called
> "R6RS Flame: Moths Wanted".
>
> I'm just looking for specific clarification on a couple of things. Nothing
> more.
>
I'm sure nobody considered your post to be intending flamewars.
(But you should give others the opportunity to use it for such
a thing)
cheers,
felix
bunn...@gmail.com
> Felix Winkelmann wrote:
> > Ahem... Weren't you a member of the R6RS editors yourself?
>
> Guilty. I was the fourth editor to resign.
> I had told the other editors (in
> a telephone conversation like the one cited by Mike
> Sperber) that we should be taken out and shot if we
> were to do what the editors ultimately did.
>
That's reasonable.
cheers,
felix
William D Clinger
> PLT Scheme resolves (foo) to SEARCH_DIR/foo/main.sls (the library is
> still named (foo) in that file). So, you can not use the same file
> name and directory structure for a library with only one component in
> its name across PLT Scheme and Ikarus and Larceny. I don't think this
> will be a problem, because in order to avoid namespace clashes,
> libraries should be named under a top-level namespace unique to the
> entity who made them, i.e. (acme foo) or (acme foo bar) and (acme)
Although it wouldn't make sense to use a name
like (rnrs) for the conglomeration of a bunch
of libraries with names like (rnrs *), and it
would be equally nonsensical to use "main" as
the name of that collection's main sublibrary,
R6RS-conforming implementations can't assume
libraries will be named sensibly.
On the other hand, I would be (indeed, I was)
the first to admit that R6RS-compatibility is
more important than R6RS-conformance.
Will
Derick Eddington
> Derick Eddington wrote:
> > PLT Scheme resolves (foo) to SEARCH_DIR/foo/main.sls (the library is
> > still named (foo) in that file). So, you can not use the same file
> > name and directory structure for a library with only one component in
> > its name across PLT Scheme and Ikarus and Larceny. I don't think this
> > will be a problem, because in order to avoid namespace clashes,
> > libraries should be named under a top-level namespace unique to the
> > entity who made them, i.e. (acme foo) or (acme foo bar) and (acme)
> > wouldn't make sense....
In my example, (acme) wouldn't make sense because it's not a
conglomeration, it's being used only as a namespace to avoid clashes.
> Although it wouldn't make sense to use a name
> like (rnrs) for the conglomeration of a bunch
> of libraries with names like (rnrs *),
I think single component names make sense for a library which is a
conglomeration and its name is the name of its creating organization/
entity.
--
: Derick
----------------------------------------------------------------
William D Clinger
> In my example, (acme) wouldn't make sense because it's not a
> conglomeration, it's being used only as a namespace to avoid clashes.
For that matter, the R6RS does not require implementations
to execute programs that import from any libraries other
than the standard libraries that are described in the R6RS
documents themselves.
Hence the fact that PLT Scheme's treatment of library names
is not fully general has no bearing upon R6RS-conformance.
Although the R6RS does not allow PLT Scheme to assume that
programs will not import from both (acme) and from (acme main),
the R6RS allows PLT Scheme to refuse to execute programs that
import from either. It's an interesting distinction.
Will