Directory listings, continued Lassi Kortela 10 Dec 2019 21:19 UTC
Re: Directory listings, continued Lassi Kortela 10 Dec 2019 21:22 UTC
Re: Directory listings, continued John Cowan 10 Dec 2019 22:41 UTC
Re: Directory listings, continued Lassi Kortela 10 Dec 2019 22:46 UTC
Re: Directory listings, continued Lassi Kortela 10 Dec 2019 22:48 UTC
Re: Directory listings, continued hga@xxxxxx 10 Dec 2019 23:44 UTC
Re: Directory listings, continued John Cowan 11 Dec 2019 00:08 UTC
Re: Directory listings, continued hga@xxxxxx 11 Dec 2019 02:00 UTC
Re: Directory listings, continued Shiro Kawai 11 Dec 2019 03:16 UTC
Re: Directory listings, continued Lassi Kortela 11 Dec 2019 10:58 UTC
Re: Directory listings, continued hga@xxxxxx 11 Dec 2019 14:13 UTC
Re: Directory listings, continued John Cowan 11 Dec 2019 15:58 UTC
Generators and object ports Lassi Kortela 11 Dec 2019 17:56 UTC
Re: Generators and object ports John Cowan 11 Dec 2019 19:29 UTC
Re: Directory listings, continued Shiro Kawai 11 Dec 2019 18:50 UTC
DIrectory handles versus directory-listing handles (and procedure naming) Lassi Kortela 11 Dec 2019 13:03 UTC
Re: DIrectory handles versus directory-listing handles (and procedure naming) Lassi Kortela 11 Dec 2019 13:07 UTC
Re: DIrectory handles versus directory-listing handles (and procedure naming) hga@xxxxxx 11 Dec 2019 13:58 UTC
Re: DIrectory handles versus directory-listing handles (and procedure naming) Lassi Kortela 11 Dec 2019 14:22 UTC
Re: DIrectory handles versus directory-listing handles (and procedure naming) John Cowan 11 Dec 2019 15:10 UTC
Re: DIrectory handles versus directory-listing handles (and procedure naming) hga@xxxxxx 11 Dec 2019 15:24 UTC

Re: Directory listings, continued hga@xxxxxx 11 Dec 2019 14:13 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Wednesday, December 11, 2019 4:58 AM
>
>>> I like directory-files because it's the dead simple API: directory
>>> path in, list of entries out (dot-files optional).  It is of course
>>> redundant with the generator interface, and would not be the end of
>>> the world to omit.
>
> We all like it, but it's up for debate where it should go. IMHO
> higher-level niceties such as glob, directory-files and various
> shell-like procedures (pwd/cd/ls/cp/mv) would go better in a separate
> SRFI or other library. Then the current SRFI would have the essential
> stuff that's hard to implement due to being OS/FFI-dependent. Stuff
> that's simple to implement using portable building blocks from this
> SRFI I would classify as higher-level abstractions.

I can see the argument for that.  On the other hand, with the
exception of call-with-temporary-filename, I think the "simple to
implement using portable building blocks" procedures already
specified and implemented in this SRFI like the other temporary
file procedures are just that, an implementor of the SRFI should
be able to take the simple supplied example code and with little or
no modification add it to their implementation.

That does imply my polishing that code, and having it reviewed by
people who's Scheme experience isn't mostly decades old.  Which
would be a good idea anyway before finalizing this SRFI.

> [ We agree close-directory is required, and implementation details
>   for read-directory, including WinAPI. ]
>
>> (define (directory-fold dir kons knil . o)
>>    (let-optionals o ((dot-files? #f))
>>      (let ((do (open-directory dir dot-files?)))
>>        (let lp ((res knil))
>>          (let ((file (read-directory do)))
>>            (if (not (eof-object? file))
>>                (lp (kons file res))
>>                (begin (close-directory do) res)))))))
>>
>> Which is called with (directory-fold dir cons '() dot-files?) [to
>> implement directory-files]. I have no informed opinion on whether it
>> should be added to the API.
>
> Since you gave very good arguments for exposing an open/read/close API,
> a fold would just be this thin wrapper around it. IMHO we don't need to
> have both APIs. (directory-fold ...) looks like it would be neat to
> implement in terms of a general (resource-fold open read close ...).

Another argument against supplying the ease of use procedures in this
SRFI, just where do we draw the lines?

- Harold