The case for glob in SRFI 170 John Cowan (11 Dec 2019 15:54 UTC)
Re: The case for glob in SRFI 170 Lassi Kortela (11 Dec 2019 18:03 UTC)
Re: The case for glob in SRFI 170 John Cowan (11 Dec 2019 19:19 UTC)
Re: The case for glob in SRFI 170 Lassi Kortela (11 Dec 2019 19:36 UTC)
Re: The case for glob in SRFI 170 John Cowan (11 Dec 2019 20:26 UTC)
Re: The case for glob in SRFI 170 Lassi Kortela (11 Dec 2019 20:45 UTC)
Re: The case for glob in SRFI 170 Shiro Kawai (11 Dec 2019 20:43 UTC)
Re: The case for glob in SRFI 170 John Cowan (11 Dec 2019 20:58 UTC)
Re: The case for glob in SRFI 170 Lassi Kortela (11 Dec 2019 21:00 UTC)
Re: The case for glob in SRFI 170 Duy Nguyen (13 Dec 2019 10:33 UTC)

Re: The case for glob in SRFI 170 Lassi Kortela 11 Dec 2019 21:00 UTC

We have exactly the same arguments :)

> support of "**"

This is probably the most important missing feature in traditional
globs. Without "**" you have to know precisely how many levels deep you
want to nest and write "*/*/*" manually.

It's like those very old Unix regexps that are missing the "." wildcard
or some such. You have only "*".

> - Glob-like matcher is sometimes useful outside of traditional
> filesystem.

Good idea. This might fit a typeclass for tree traversal. We probably
can't make zippers work?
<https://en.wikipedia.org/wiki/Zipper_(data_structure)>

> (To be precise,
> posix does provide alternative subsystem via GLOB_ALTDIRFUNC, but to use
> that from Scheme there would be lots of C-Scheme hopping needed.)

This is a good example of the kind of problem that libc causes with
high-level languages. It can be better to implement the same thing from
scratch in the HLL. The C interface would have so many workarounds that
it adds up to the same amount of code.