Comments | fare: Who's responsible for that moving part?

fare

Who's responsible for that moving part?

Feb 10, 2009 13:20

Common Lisp pathnames have long been a source of frustration ( Read more... )

extensibility, lisp, tao of programming, social fabric, filesystem, programming languages, en

Comments 7

selfishgene February 10 2009, 20:14:56 UTC

The stuff about statists and judges seems minimally relevant to this screed.

An offer you can't refuse fare February 10 2009, 23:19:01 UTC

It's about the fact that there's worse than bad contracts that you can refuse to opt in: bad statutes that you can't refuse to opt in. "I'm going to make you an offer you can't refuse..."

I could possibly have articulated the idea better.

CL-FAD? anonymous February 10 2009, 21:41:56 UTC

There is also http://weitz.de/cl-fad/ - yeah, not on the same level as IOLIB+CFFI - but better than *defaults*... that reminds me... *default-pathname-defaults* - gah!

Re: CL-FAD? fare February 10 2009, 23:17:30 UTC

I looked at it. From not handling byte-oriented filenames or symlinks to confusingly calling "breadth-first" what is actually "inspect *before* you recurse", it is broken in more ways than I care to describe. It is not something you want to rely upon, much less standardize.

So true anonymous February 11 2009, 08:30:12 UTC

You got it right. Common lisp is stagnated.

anonymous February 15 2009, 11:16:47 UTC

As one who has never quite understood the incessant whining about CL's ( ... )

anonymous February 21 2009, 00:57:12 UTC

CL pathnames are seriously underspecified which means that there are totally legitimate corner cases where they behave differently on the existing CL implementations.
Also, they unnecessarily conflate two loosely related concepts: file names and pattern matching, creating such corner cases.

You're right that the content type is an important attribute of a file, but that has nothing to do with the file's name: GNOME and KDE both scan the files' headers to detect content type meaning that you can easily have an MP3 file named README.txt for instance. As usual, Window$ sucks in this particular respect. If you're looking for a good example, that is BeOS - which stored the file's MIME type as extended attribute in the FS.