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?

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