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] |
Christian Lynbech <chl@tbit.dk> writes: > The patch was sent to bug-guile, but there was never any feedback. I > can dig it up if anybody wants to see it. No need for that, I just put it up on my patches page (it took far too long to get it up, though... I'm lazy when it comes to fiddling with mime stuff ;) http://home.thezone.net/~gharvey/patches It seems to work quite well, though I haven't done anything rigourous with it. > In fact I have been dreaming about reorganizing guile such that we had > a core which had no concept of files or I/O or anything. There would > only be a generic notion of ports, such that load would accept ports > and work directly with that without caring about how it had come to > be. > > Creation of ports would then be the domain of additional libraries, > such as a posix library or a stdio library that would provide > functions such as `open-input-file´. Compability with RnRS would be > provided by translation functions. If `load´ was given anything other > than a port, it would call a specific function, lets call it > `pathname->port´, that would do the translation. The posix library > would then provide a hook for pathname->port that would know how to > convert a string to a port by opening the file designated by the > string. This could be very cool, though it might be a bit difficult to have more than one type cooperating (this would probably be a good place to use an object system, so that you can have a concrete way of determining which open method gets called in what order). -- Greg