put library <body> at top-level Per Bothner (30 Nov 2005 20:33 UTC)
(missing)
(missing)
(missing)
(missing)
Re: put library <body> at top-level Per Bothner (03 Dec 2005 16:16 UTC)
Re: put library <body> at top-level Ray Blaak (03 Dec 2005 16:17 UTC)
import suggestion Ray Blaak (03 Dec 2005 16:17 UTC)
Re: put library <body> at top-level Matthew Flatt (30 Nov 2005 22:20 UTC)
Re: put library <body> at top-level Per Bothner (30 Nov 2005 22:29 UTC)
Re: put library <body> at top-level Bradd W. Szonye (03 Dec 2005 16:16 UTC)

Re: put library <body> at top-level Per Bothner 30 Nov 2005 22:27 UTC

Matthew Flatt wrote:
 > Consider an e-mail message like Andre's, which includes multiple
 > library definitions. If a library is identified with a file, then the
 > e-mail author must invent an ad-hoc notation to indicate the names and
 > content of files.

A standard notation exists: It's called MIME.

If you're actually distributing real libraries (as opposed to
explaining / asking questions), you should use attachments.
Code inline in message bodies is not reliable.

A Scheme-specific packaging format is neither needed nor sufficient.
If you need to distribute multiple library files, you may also need
to include other resources that are not Scheme files, such as photos
or sounds.

OpenDocument uses .zip, while seems a fine choice for bunding a group
of libraries and their resources and meta-information.  (A Java .jar
or .war file is basically just a .zip file.)

 > Others can offer additional arguments. I know, for example, that some
 > would like to include multiple library definitions in a single file,

Others want multiple files for a single logical library.  (XQuery
sort-of-does that.)

Note one could define extensions that allow multiple libraries in
a file, but I don't think it very useful: From a code management
or pragmatics point of view it seems a bad way of doing things.
If a library is small enough you can fit more than one in a file,
then why do you want it as a separate library?

 > and others object more generally to the notion of "file" in a
 > specification of syntax.

Well, if we're talking about separate compilation you want some
kind of physical separation.  That separation is a file.

 > Overall, it may be best to think of the SRFI's syntax as an
 > interchange format.

Why?  Because it solves a non-existing problem badly?

 > Suppose you have
 >
 >  1. An implementation that connects files to libraries, and
 >
 >  2. tools that pack and unpack library files into the SRFI's stream
format.
 >
 > Doesn't that preserve most of the practical advantages? (For example,
 > PLT Scheme connects libraries and the filesystem, and it will be easy
 > to write packing and unpacking tools for PLT Scheme.)

Because that adds extra complication for no good reason.
It's more configuration/glue magic that people have to learn
and use.  People understand files and filenames.

 >>There is
 >>too much indentation and parentheses as it is
 >
 > We need a notation to group a module declaration with its body.

We don't, if the grouping is implicit: a declaration in a module
is grouped with the module, because it's in the same file.

Obvious, intuitive, flexible.  Uses the tools and concepts we have.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/