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: Drew Adams
Subject: RE: empty-directory predicate, native implementation
Date: Sat, 17 Oct 2020 14:18:19 -0700 (PDT)

> > 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.



reply via email to

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