This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Path searching.



(I've snipped down the cc line)

Christian Lynbech <chl@tbit.dk> writes:

> >>>>> "Greg" == Greg Harvey <Greg.Harvey@thezone.net> writes:
> 
> Greg> This could be very cool, 
> 
> This is just what comes from working in a very non-standard,
> suboptimal, far-from-posix, sort-of-embedded kind of environment.
> 
> Greg> though it might be a bit difficult to have
> Greg> more than one type cooperating (this would probably be a good place to
> Greg> use an object system, so that you can have a concrete way of
> Greg> determining which open method gets called in what order).
>  
> I think we should keep it as simple as possible and thus not tie it
> intimately with objects systems.
> 
> A simple scheme would be to rely on a particular translation
> functions. For instance, `load' would work as follows. It would
> examine its argument, if it is a port continue with that. If it is
> not, call `translate-path' on the argument. 
> 
> `translate-path' (a semi-arbitrarily chosen name) would be responsible
> for translating whatever argument into a port. The default definition
> would accept a string which should designate a file valid for
> `opne-input-file'. Each function that support translation would have a
> documented translation function to call on non-port objects.
> 
> A user with a more sophisticated need would provide a new definition
> of `translate-path', for instance to recognize urls, in order to
> support the loading of scheme "files" directly off an web server.

This could probably be worked around the hooks mechanism (have, say
translate-path-<type> be a set of hooks that can potentially turn an
argument of type into a port, and the stop on the first one that
returns a port, though I don't think there's a simple way to
short-circuit run-hook right now, which is essential for this to work
nicely). It would be pretty simple, but flexible enough for most uses.
 
> So the simple customization consists of redefining the documented
> translation functions (there can be more than one, but
> `translate-path' is the only need I can think of right now). More
> sophisticated schemes could be provided by apropriate overloading,
> either by an object system or some table based thingy and can come
> later (or follow the relevant extension, not everybody will want
> object systems).
> 

-- 
Greg