Re: [Scheme-reports] Ballot item #113 "directory contents"

[Alex Shinn <alexshinn@x>]

On Tue, Jan 11, 2011 at 9:30 PM, pod <pod@x> wrote:
> Apologies, but the previous message was both truncated and had the
> formatting screwed up.  I'm not sure I can ensure the formatting is
> preserved but I attempt to paste in the full message below.  You may
> be glad to hear that if this attempt also fails I shall give up -
> communicating with scheme-reports-wg1 is turning out to be just too
> hard.

scheme-reports-wg1 is the member-only mailing list.
For public discussion you want:

  http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports

to which I'm forwarding this.

> Please forgive my interjections but I couldn't help noticing that the
> current ballot item #113 "directory contents" seems rather lacking in
> detail and does not got far enough in providing functionality
> necessary for "a large class of scripts".  The info paragraph for this items
> reads:
>
>    We've decided to add file-exists? and delete-file, essential for a
>    large class of scripts, but still have no way to get a list of files in
>    a directory. Do we want to provide an interface to this?

The term "large class" of scripts does not preclude the existence
of even larger classes of scripts which are still not possible.  It's
still a significant step up from R5RS.

In particular, directory-files is in a sense more primitive than
file-exists?, since the latter can be implemented (inefficiently)
in terms of the former.

> My concern is that the current proposals (if I understand them
> correctly) still do not provide enough essential functions for a sufficiently
> large class of scripts to be written - for example scripts that wish to
> (recursively) walk a directory tree.
>
> The most glaring problem seems to be the lack of a directory?
> predicate with which one can determine (given the list of directory entries)
> whether or not to descend into that directory or to process the entry as
> naming a file-like entity.

Technically you could define directory? as:

  (define (directory? x) (file-exists? (string-append x "/.")))

(modulo separator concerns), but the point is well taken.
WG2 will include a full filesystem interface, and in WG1 we
have to decide if we want to cherry pick any functions,
include everything, or continue to be as useless as R5RS
in this respect.

One of the rationales in the first ballot pointed out that
just adding file-exists? and delete-file was silly.

> A secondary problem, which may indeed be considered well out of scope
> for both WG1 and WG2 is that of:
>
>  - (portably) determining a directory entry separator character with
>    which to form a string to pass to open-directory (or directory-
>    files or whatever) when wishing to descend into said directory
>
>  - lack of a function to change the current working directory
> (obviating
>    the need to know the platform specific directory separator
> character).
>    [Not that I would advocate writing code that worked this way.]

I consider both of these well within the scope of WG2.

> For sure <http://trac.sacrideo.us/wg/wiki/DirectoriesCowan> proposes
> (directory? filename) but I don't see this directly linked to from
> item
> #113 and thus whether it is considered as part of item #113.
>
> In addition I don't see a tight definition of directory-files.

Many of the proposals at the initial ballot level are
intentionally vague, with details to be filled out only
when and if the general idea is accepted.  Most Scheme
implementations have something akin to directory-files
which does the same thing modulo a few variations (e.g.
whether or not to include "." and ".."), so I felt just that level
of description was at least usable as an option.

Individual members can always supply more detailed
proposals, and John Cowan has done an excellent
job of filling in the details of some of the more egregiously
vague descriptions with proposals of his own.  In this
case, his DirectoriesCowan proposal is for WG2, and
DirectoryPortsCowan is an option for WG1 item #113.

-- 
Alex

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