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.