On Mon, 2010-03-08 at 13:42 -0500, R. Kent Dybvig wrote:

> The cause of our differing views on encoding might be a difference in
> perspective regarding the purpose of library names.

That's definitely it, which I'd not known.  Thank you for helping
explore this.  I think I have a pretty good justification of why my
perspective is better, explained throughout the below.

> From my perspective,
> library names serve as an abstract way of specifying file names, which is,
> in fact, one reason why they are structured as they are.  There shouldn't
> be any restriction on the file names we can specify with a library name,

In my view, library names specify libraries, which are conceptually
different than files even if they're sometimes contained in files, and
they are for specifying module interfacing, and they are not dependent
on any particular data storage models.  I consider that a major
improvement over specifying libraries and module interfacing with
platform-specific file names.  They have compound structure because it's
useful, not because they're a representation of a file name.  File names
should serve the higher purpose of library names.

If the desired name for a library, made by a Windows user, includes the
Windows-disallowed characters/names, they should be able to use that
name.  In 100 years when Windows and unixes are long gone, I want that
library to be named as desired, and without the hassle of renaming every
occurrence of it at some future time.  Also, until Windows dies, Windows
users should be able to choose the most appropriate library names so we
can all benefit from not being confused/frustrated by inappropriate
names.

I look forward to the future of significantly different OSs and data
storage models.  I don't want libraries which should have been named the
most appropriately to not be because we viewed library names as less
than they should be because of the influence of outdated OSs (unixes
included).

> and there's no need to be able to specify file names that don't exist.
> For libraries intended to be used on two or more platforms, there's no
> need to be able to specify file names that don't exist on both.

(... but we're specifying libraries, not files.)

Here's an example of a need for supporting arbitrary symbols.  I've had
an idea for customizing the lexical syntax.  If an unknown #!symbol is
read, (eval 'handler (environment `(acme custom-handlers ,symbol))) is
done at read time to get the handler for the non-standard lexical syntax
which follows.  Ignoring what I haven't explained and all the details I
haven't fully explored, such use of dynamic library names in general
seems to clearly be a good reason for supporting arbitrary symbols.  I
also have another idea which could take advantage of that method of
dynamically loading.  Clients must be able to give any symbol, and a
third party may be responsible for providing the library; so, for the
files of all such possible libraries to be auto-loadable on Windows, the
special mapping of Windows-disallowed file names is necessary.

> > No, because file-name strings are inherently platform specific.  Library
> > names (for portable libraries) are supposed to be completely abstracted
> > from any platform, and that's why I'm convinced allowing them to be
> > determined by the flaws of platforms is unacceptable.
>
> I don't want to push the analogy too far, but library names (like strings)
> are platform independent as long as they are internal to a Scheme system.
> They become platform dependent (like strings naming files) as soon as you
> try to tie them to a file system, which is what the SRFI is all about.

The SRFI is tied to unixes and Windows only so it can define a mapping
of library names to those OSs' file names.  The compound library names
correspond decently with those OSs' file systems, but I've never viewed
library names as tied to any platform.  File names specify things which
are tied to the OS level.  Libraries are quite often not tied to any OS,
so their names should reflect that.

There very well may be OSs with a totally different data storage system,
on which our libraries will be used.  So, I can't support allowing our
libraries' names to be determined by the OSs we're using now, when the
appropriate library names should have been used and are resolvable in
other OSs' storage systems in a perfect way.

> > That's not portable and SRFI 103's purpose is supposed to be portability
> > across prevalent OSs, so it's not supposed to be concerned with that.
> > That can be portably accomplished with libraries named like
> > (personal ---) and (for unixes) placing the "personal" directories in
> > home directories and doing
> > SCHEME_LIB_PATH=$HOME/wherever:$SCHEME_LIB_PATH.
>
> The SRFI's purpose is portability, but it shouldn't prevent the naming of
> other files in import forms.  In particular, it shouldn't prevent a
> programmer from (unportably) specifying ~/.myappinit, but the proposed
> encoding requirement does just that.

If you want library names to be a representation of file names, I can
understand.  (But I strongly don't want them to be that.)

> Your proposed workaround is
> cumbersome

I agree it's not as super-minimal, but I don't think it's cumbersome
with one site-wide "rc" login environment-setup script used by multiple
users and with users already having collections of other libraries in
their home directories.

> and not very unixy.

IMO, that's often a good thing.  Windows is certainly worse, but I'm not
a fan of unix either (and I use Linux predominately).

> > Actually, the joining of relative library-file names with
> > searched-directory names is what prevents that (assuming I'm
> > understanding what you mean).  Without the encoding, a library named
> > (/ foo), with SCHEME_LIB_PATH=/exploit, will be found
> > at /exploit///foo.ext.
>
> That's true with the SRFI as defined, but it is common to ignore search
> paths when absolute pathnames are used, so (/ foo) should be found in /
> and (c:/ foo) under Windows should be found in c:/ no matter what the
> search path contains.

If you want to override the SRFI to catch such library names, you can
also map them to a file name without the SRFI's encoding (maybe just the
"absolute path" first symbol).  Same for ~.

In conclusion, I don't see why considering library names as
representations of contemporary file names is proper, and I don't see
why it outweighs the importance of abstract unrestricted library names.

--
: Derick
----------------------------------------------------------------