emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: empty-directory predicate, native implementation


From: Arthur Miller
Subject: Re: empty-directory predicate, native implementation
Date: Sun, 18 Oct 2020 00:06:08 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Drew Adams <drew.adams@oracle.com> writes:

>> > Sorry I'm coming to this late.  It's a long thread,
>> > and I've only checked your patch, not the messages.
>> >
>> > I don't understand why we would do this.  Is the
>> > real aim to be able to have an empty-directory
>> > predicate, i.e., to be able to see if there are
>> > no files in a directory?
>>
>> Yes.
>>
>> > If so, then why not do just that, without
>> > bothering (changing the signature of)
>> > `directory-files'?
>>
>> Because it is not possible to that efficiently with current elisp; how
>> would you do that directly? OS does not have such call, one have to
>> iterate through directories. At least I am not aware of such call. If
>> you know, please tell me, I would be happy to use it, at least for myself.
>> 
>> Fastest I am aware of is to get a buffered list with SYS_getdents and then
>> check for first non-dot file. That changes complexity from linear in
>> number of files in directory to constant (3 files at max). It works only
>> on Linux kernel, and I don't know if there is nt version of such call,
>> or what there is on macs.
>> 
>> I suggested such predicate, but to not re-iterate entire discussion, pls
>> check my first mail and followed 2 or 3 I think.
>
> I took a quick look at the first few messages etc.
>
> I see that Eli suggested not implementing an
> empty-directory predicate directly but instead
> adding a COUNT parameter to `directory-files' (Lisp).
>
> That's just what I questioned.  If the aim is an
> empty-directory pred then why not code it in C, like
> we do `directory-files'?  And instead of duplicating
> code, if that would be the case, extend the C code
> underlying `directory-files' to be usable also for
> such a predicate, stopping as soon as it finds one
> file.
>
> IOW, what you've done, but not expose the COUNT
> parameter to Lisp.  If its real purpose is just to
> check for emptiness, then from Lisp I'd think we'd
> have a separate predicate for that, and we wouldn't
> change the signature of `directory-files'.
>
> UNLESS there really IS some use for a COUNT value > 1.
>
> That was my question.  If there's some use case, in
> Lisp, for COUNT, i.e., for returning the "first" N
> files, then fine.  But if not, I don't see why we
> would add COUNT to `directory-files' (Lisp), as
> opposed to just getting the emptiness check from C
> (perhaps by adding a COUNT there, but not changing
> the Lisp interface for `directory-files').
>
> Not a big deal.  Just a question; just something
> that occurred to me when I saw this.  I think a
> Lisp user is likely to ask herself the same thing:
> apart from passing 1 for COUNT, why would I ever
> use COUNT?
>
> And if it were agreed that there's no use case for
> COUNT > 1, but for some reason a separate predicate,
> `directory-empty-p' isn't wanted, then change COUNT
> to a Boolean parameter that just says you want an
> emptiness check.
>
> If COUNT > 1 has no utility then, if you have to add
> a parameter for Lisp, its name, doc, and behavior
> should at least be more indicative of its purpose, no?
>
> Don't get me wrong.  I'm generally in favor of Lisp
> Boolean functions and such that return useful non-nil
> truth values.  I _really_ like that.  But here I don't
> see the usefulness of the non-nil return value, which
> means the thing will confuse and mislead sometimes.
>
>> > Is there really some use case for getting only
>> > the first N files in a directory?  I can
>> > understand wanting to test whether a dir is
>> > empty.  I can't see why someone would want the
>> > first N files (however "first" might be defined).
>>
>> Probably not; it is just a result of having count parameter.
>
> Should be the other way round, no?  We should have
> a COUNT parameter only if it's useful.  If we're
> adding it just for implementation purposes, then why
> not just do that under the covers in the C code?
>
> Anyway, I don't mean to belabor this.  I've asked
> my question and clarified why I asked.

Yeah, sure; I completely buy your reasoning. When I think of, one user
case for COUNT is maybe if a user have some kind of limited structure to
fill and just wish to taken N number of files. I don't know if that is
very common in Elisp, it's not directly a system programming lang, so I
think it is an artifical example.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]