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@bothner.com   http://per.bothner.com/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports