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