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] |
(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