Email list hosting service & mailing list manager

Re: upcoming revision, need feedback R. Kent Dybvig (11 Jan 2010 20:52 UTC)
Re: upcoming revision, need feedback Derick Eddington (12 Jan 2010 02:11 UTC)
Re: upcoming revision, need feedback R. Kent Dybvig (12 Jan 2010 03:52 UTC)
Re: upcoming revision, need feedback Thomas Bushnell BSG (12 Jan 2010 04:24 UTC)
Re: upcoming revision, need feedback Derick Eddington (12 Jan 2010 06:18 UTC)
Re: upcoming revision, need feedback Thomas Bushnell BSG (12 Jan 2010 06:27 UTC)
Re: upcoming revision, need feedback Derick Eddington (12 Jan 2010 07:05 UTC)
Re: upcoming revision, need feedback Thomas Bushnell BSG (12 Jan 2010 07:16 UTC)
Re: upcoming revision, need feedback Derick Eddington (12 Jan 2010 09:00 UTC)
Re: upcoming revision, need feedback R. Kent Dybvig (27 Jan 2010 20:58 UTC)
Re: upcoming revision, need feedback Derick Eddington (28 Jan 2010 00:45 UTC)
Re: upcoming revision, need feedback Vitaly Magerya (28 Jan 2010 10:39 UTC)
Re: upcoming revision, need feedback Derick Eddington (28 Jan 2010 17:45 UTC)

Re: upcoming revision, need feedback Derick Eddington 28 Jan 2010 17:37 UTC

On Thu, 2010-01-28 at 12:45 +0200, Vitaly Magerya wrote:
> Derick Eddington wrote:
> > The social solution has the problem that people would be guessing what
> > characters they shouldn't use, leading back to the current situation of
> > trying to get everyone to be consistent.  Unfortunately, we can't remove
> > the OS restrictions which make the additional feature of encoding
> > necessary.
>
> We can with a slightly different design. Instead of specifying the
> mapping from a library name to a filename, you can specify the reverse
> mapping, and then let e.g. a tool to generate the catalog with the
> direct one. In this design you'll be permitted to escape any character
> at your discretion, and your libraries will still be found.
>
> This is basically how SLIB manages packages.
>
> This will also allow libraries with names "aux", "con", "nul" and "prn"
> to exists (as e.g. %61ux.scm or pr%6E.scm); in the current design they
> can't because it's impossible to create aux.scm in Windows.
>
> But don't get me wrong, I'm only listing a possibility, not advocating
> the design.

I actually already explored that, because of its advantage of flexible
encoding.  I decided against it because: (1) it requires renaming
library files when exchanging them across platforms; (2) regenerating
the registry every time a library file is added or removed is
unacceptable (IMO); (3) without a pre-generated registry, the speed of
finding library files, by listing every directory up to the last
library-name component and decoding all entries, scales very badly (even
with a cache), for realistically larger sets of imports with
realistically larger sets of available library files, such that program
start-up speeds would be unacceptable.

About Windoze's "aux", "prn", etc. disallowed file names, I don't know
what to do.  Part of me wants to leave it unsupported as a surprise for
users, to enrage them to revolt against Windoze; but maybe that means
the encoding should be removed, to cause more rage against Windoze..?
By the same justification for the encoding, I suppose this SRFI should
do something to make library files with those names work for Windoze,
e.g. by encoding the first character.

(Windoze -- many trillions of person-hours wasted dealing with its flaws
-- perhaps an ingenious strategy of the evil power elites to continue
restricting the serfs as increasing technology threatens to free them.)

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