Scheme language standardization process
On 01/12/2011 09:51 PM, John Cowan wrote: > Per Bothner scripsit: > >> I put quite a bit of thought into it - for example into issues like >> where the slashes go when taking apart paths/URLs. > > http://trac.sacrideo.us/wiki/PathnamesCowan is the same basic idea, > but with features drawn from CL (and therefore MIT Scheme) as well. > If you have a chance, I'd appreciate a critique of it. The support for "wild" components adds some extra power, but it adds a lot of complexity. And it's still not very general - it only supports a very restricted form of globbing. And at the cost of not being able to map generally to URIs. And how does someone make use of a pathname with a wild component? I recommend dropping the feature. Similarly version numbers: Nobody uses them and most people don't know what they are. Many (most?) of us seem to believe that version numbers were a mistake for library names; I think it would be a mistake to standardize them for pathnames. If think having both pathname-query-as-string and pathname-query is awkward. I also think defining a the query as either a string or an alist is awkward - just define it as a string, and add some extra utility routines: either a routine that takes a query string and yields an alist; or a routine that takes a pathname and returns the query string as an alist; or a routine that takes a pathname and a query key and returns the corresponding query value. I'm not sure the options parameter in various functions is needed or desirable. We already got rid of 'version. The use of 'windows seems inconvenient: You want 'windows to be the default on Windows but only on Windows. The use case for being able to part to Windows filename convention on Posix and Posix filename convention on Windows is pretty rare. The only one I can think of is people running CygWin or other Posix-oriented tools on Windows. So yes, if you have a library to support ScSh-style functionality or a Posix interface, yes then you'd probably want functions for conversion between Posix and Windows filenames. But I don't think it should be in core pathname API. Note the concept of "directory" isn't really well-defined in the URI world. Informally, a directory may be a path/URI that ends in "/". However, a web server will usually just ignore the final slash and this not distinguish between files and directories. In my API I went a slightly different way: Basically a pathname is an object that is isomorphic to a URI. The various library routines are defined as string operations: They are useful and meaningful when the strings are interpreted as filenames and URIs, but the *definition* of the operations should independent of any underlying file or server objects. merge-pathnames should be defined so it is compatible with the URI "resolve" operations. -- --Per Bothner per@x http://per.bothner.com/ _______________________________________________ Scheme-reports mailing list Scheme-reports@x http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports