[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: remaining issue

This page is part of the web mail archives of SRFI 103 from before July 7th, 2015. The new archives for SRFI 103 contain all messages, not just those from before July 7th, 2015.

[I've already suggested to Aaron to join the mailing list.]

On Sat, 2010-03-06 at 19:59 -0500, Aaron W. Hsu wrote:
> On Sat, 06 Mar 2010 19:45:33 -0500, Derick Eddington  
> <derick.eddington@xxxxxxxxx> wrote:
> > I disagree and cannot support that.  That's imperative style and not
> > compatible with Scheme systems which don't have some outside context
> > from which to execute the loading.  R6RS libraries are supposed to be
> > usable as the fundamental source-code unit, which necessitates
> > auto-loading of imports.  I think being compatible with systems which
> > have an outside context (e.g. a traditional top-level) is good, but SRFI
> > 103 must not discourage the use of all possible library names (because
> > I'm not going to support corrupting symbols' usefulness) in systems
> > which do not have that.
> All you have to do is make sure that whatever implementation loads them  
> gets those libraries somehow. You could do this by passing them on the  
> command line or many other ways of doing it. 

I can't assume that every Scheme system will have a somehow for
explicitly loading.  That most systems will is not a clear enough
argument for why non-portable non-auto-loadable library-file names are

> I'm not saying its the best  
> solution, but I'm not really excited by having a ton of files littered  
> around that have encodings on them. 

I'm not excited about it either, and I've already been dealing with it a
lot (because of maintaining an SRFIs collection), and I'm okay with
continuing to do so if portability with Windoze helps grow Scheme
adoption.  Further, if exact integers are allowed in library names like
they should be, the SRFIs will be renamed like (srfi 1 lists) which will
make all those encoded colons go away, and then there won't be a ton of
encoded-character file names because most of everyone's library names
won't cause them.
> Moreover, I don't want encodings to be  
> used if my implementation and underlying file system can handle the  
> library without it.

I feel the same way, but we need to thoroughly consider the benefits of
playing nicely with Windows users.

: Derick