Hi, Andy Wingo <wi...@pobox.com> writes:
> On Tue 20 Apr 2010 01:12, l...@gnu.org (Ludovic Courtès) writes: > >> Andy Wingo <wi...@pobox.com> writes: >> >>> I recently added a global fluid, %file-port-name-canonicalization, which >>> defaults to #f. But if it's 'absolute, the port name of a file port will >>> be canonicalized to the absolute path; or, if it's 'relative, the port >>> name is the canonical name of the file, relative to the %load-path, or >>> the file name as given otherwise. >>> >>> The intention was to allow the user to control (port-filename P), so >>> that the user could find e.g. the absolute path corresponding to that >>> port at the time that it was made. >> >> My feeling is that ports shouldn’t have to deal with paths because >> that’s a separate concern. The %file-port-name-canonicalization fluid >> seems like an inelegant hack to me. >> >> When applications have special requirements about paths, then it should >> be up to the application logic to deal with that. IOW, applications are free to do: (open-input-file (canonicalize-path filename)) instead of: (open-input-file filename) And that’s all it takes at the application level. > 2. I think a fluid is still necessary, because a file being > compiled can do an `include' or `include-from-path', or even > `open-input-file' in a macro, and all these cases you would want the > same %file-port-name-canonicalization to take effect. Indeed, this one is tricky. I still think it’s application-specific, though. How about calling the fluid, say, %compiler-file-name-canonicalization instead? :-) > 3. The only correct time to do a path canonicalization is when the file > is opened, because at another time, you might not be in the same current > directory, so relative paths would resolve incorrectly. Yes. > 4. The application-level code is nastier if it has to canonicalize, > because a relative canonicalization What do you mean by “relative canonicalization”? (I have Glibc’s ‘canonicalize_file_name ()’ in mind, which returns an absolute path, so I’m confused.) > cannot in general be passed to open-input-file. For example > > (open-input-file "../../module/ice-9/boot-9.scm") > > is not the same as > > (open-input-file "ice-9/boot-9.scm") Agreed. :-) > So you'd have to do a set-port-filename! on the port, mucking up your > code -- and how would you decide what to set? In N places you'd have to > duplicate fport_canonicalize_filename, and you'd probably have to make > scm_i_relativize_path public. I failed to get the transition at “So”. :-) What does scm_i_relativize_path do? (It lacks a leading comment, hint hint. ;-)) Thanks for taking the time to explain! Ludo’.
