Hi Noah, Thanks for thinking about this thorny issue.
Noah Lavine <noah.b.lav...@gmail.com> writes: > Group 1: Treat pathnames as opaque objects that come from outside APIs > and can only be used by passing them to APIs. We can support these in > a way that will be compatible everywhere. > Operations: open file, close file, stat file. > In order to be useful, we might also provide a > "command-line-argument->file" operation, but probably no reverse > operation. Unfortunately, we'd need more than just that one operation. What if you need to run an external command on a filename received from readdir? For this you need `file->command-line-argument'. What if you need to put that filename into an environment variable? Then you need `file->environment-variable-value'. What if you want to use an environment variable's value (which contains a filename) to either open the file directly or call an external command on it? For this you need `environment-value->file' or `environment-variable-value->command-line-argument'. What if you want to put a command-line argument into an environment variable? For this you need `command-line-argument->environment-variable-value'. What if you want to split the PATH environment variable (or another one like it) up into components, and then use those components to either read those component directories from scheme, or run external commands on those components, or put the components into environment variables? Also, what are we to do about backward-compatibility for all of the existing POSIX interfaces in Guile which have always returned strings? What are we to do with procedures like `program-arguments', `command-line', `environ', `getenv', `readdir' and `passwd:dir'? What can we pass to `main' that would both incorporate this new distinct command-line-argument type and maintain backward compatibility with scripts that expect strings? Best, Mark