<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br>
<br><div><div>On 24 Sep 2014, at 08:13, Ville Voutilainen <<a href="mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On 24 September 2014 08:59, Mark Evenson <<a href="mailto:evenson@panix.com">evenson@panix.com</a>> wrote:<br><blockquote type="cite"><br>On 24 Sep 2014, at 06:05, Pascal J. Bourguignon <<a href="mailto:pjb@informatimago.com">pjb@informatimago.com</a>> wrote:<br><br><blockquote type="cite"><br>Why do we have?<br><br> (wild-pathname-p #P"*-blah") -> T<br> (wild-pathname-p #P"*-blah" :name) -> NIL<br><br>This is inconsistent (and non-conforming).<br></blockquote></blockquote><br>Looking at the java code, it seems a bit naive/lazy. The memq for the<br>directory does catch<br>directories like foo/bar/*/baz (which _are_ wild), but it also<br>seemingly catches other<br>cases like foo/bar/baz*baz/otherstuff. I'm not convinced this is<br>non-conforming, though,<br>since implementations are allowed to support implementation-dependent<br>strings that<br>contain wildcard characters, which is what we do.<br><br>Having said that, in such cases I usually prefer doing what sbcl does,<br>as far as possible. :)<br></div></blockquote></div><div><br></div><div>I’m not sure this is advisable with respect to pathnames. sbcl is strongly influenced by cmucl, and cmucl is not the best implementation about pathnames, IMO.</div><div><br></div><div>That said, the wild-pathname-p implementation should rather be consensual, CLHS doesn’t seem to leave much to implementation choice in it.</div><div><br></div><div>Only, it shall depend on how the implementation supports wild components.</div><div><br></div><div>For logical pathnames, there are :wild components and wildcard-word (or also wild-inferior-words for directories) components (they must be both supported).</div><div><br></div><div>For physical pathnames, only :wild or :wild-inferiors components must be supported, but of course, it is highly advisable to document and support wildcards in physical components too.</div><div><br></div><div>And since we also want to support POSIX paths as physical pathnames, which may contain any sequence of byte, we want to distinguish physical pathname syntax, from plain POSIX paths.</div><div>(Let’s also keep in mind that POSIX paths may contain any control character and any sequence of byte that is *invalid* UTF-8 (apart from 0)).</div><div><br></div><div><br></div><div>I’m reminding all this, because foo/bar/baz*baz/otherstuff is ambiguous:</div><div>- it may be a physical pathname syntax with a wildcard-word component using a syntax similar to logical pathnames, ( #P"foo/bar/baz*baz/otherstuff” ), or</div><div>- it may be a native pathname string representation of the POSIX path #(102 111 111 47 98 97 114 47 98 97 122 42 98 97 122 47 111 116 104 101 114 115 116 117 102 102).</div><div><br></div><div>In the first case, it’d be a wild-pathname, in the later case, it wouldn’t be.</div><div><br></div><div><div>— </div><div>__Pascal Bourguignon__</div><div><br></div></div></body></html>