Per Bothner wrote:
> Matthew Flatt wrote:
>> 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.

I would have thought that from a Scheme point of view, the standard
notation would have been the S-expression.

> A Scheme-specific packaging format is neither needed nor sufficient.

Some kind of packaging is needed to bundle up multiple expressions into
a single library, whether it's explicit parenthesisation or implicit in
the boundaries of the containing construct.

Should this SRFI mention all the various kinds of containers, files and
file-like constructs that can appear in all the different variants and
versions of operating systems big and small? Should it mention MIME?
Should it require MIME? Should it mention the .zip format? Should it
require it?

All of this complexity can be avoided if you use Scheme data structures
to aggregate Scheme data structures, without reference to
operating-system specific (and possibly even absent) constructs such as
files and directories.

> 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.

That's true, but expands the discussion - it's not to the point of
libraries of Scheme *code*.

>> 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.

That's not true - the separation is purely logical. Imagine a Scheme
that was image-based, like a Smalltalk, with an in-core representation
of its own source-code and an editor for these in-core data structures.
Separate compilation is still both desirable and feasible - no reference
to operating-system-level byte-containers is needed.

> People understand files and filenames.

That's true, but only where files and filenames are part of the
environments people use.

>> 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.

It's still a means of grouping forms together, except instead of being a
notation, it's a convention - worse yet, it's a convention that relies
on external non-Scheme second-class objects.

> Obvious, intuitive, flexible.  Uses the tools and concepts we have.

I'd say the same about sequencing/grouping forms using a list - lists
are about the most obvious, intuitive, flexible, and *original*
construct in the entire Scheme language!

Regards,
  Tony