<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Juanjo,<div><br></div><div>On 13/10/2011, at 6:48 PM, Juan Jose Garcia-Ripoll wrote:</div><div><div><div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Thu, Oct 13, 2011 at 1:24 AM, Mark Cox <span dir="ltr"><<a href="mailto:markcox80@gmail.com">markcox80@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<div class="im">I have two issues with respect to the merging of DELETE-FILE and</div><div><div class="h5">
RMDIR:<br>
<br>
1. For physical pathnames it seems straightforward, but I do<br>
wonder if there are any unexpected gotchas when using logical<br>
pathnames.<br></div></div></blockquote><div><br></div><div>Understood, but here the user must understand that logical pathnames are not physical objects. An invalid pathname translation also has problems with delete-files, as it would do one that changes a file into a directory and viceversa.</div></div></blockquote><blockquote type="cite"><div class="gmail_quote">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">2. DELETE-FILE is defined by the CLHS. People who use ECL without<br>
reading too much of the CLHS may expect DELETE-FILE to behave<br>
similarly across implementations. For example, it was a huge shock to<br>
me that in CLISP, PROBE-FILE signals an error when called with a<br>
pathname that represents a directory.<br></div></div></blockquote><div><br></div><div>This is a different field. So far no implementation has restrained from having unspecified behavior because ECL users might be confused, and this includes incorrect LOOP forms, but this is not the case. As Waldek pointed out, the key point is the definition of file (<a href="http://clhs.lisp.se/Body/26_glo_f.htm#file">http://clhs.lisp.se/Body/26_glo_f.htm#file</a>), which talks about a named entry in the file system. If ECL already considers directories to be valid files for PROBE-FILE, then it is inconsistent in not allowing to delete them, and failing to rename them for some fo the syntaxes.</div></div></blockquote><div><br></div><div>I agree that DELETE-FILE should be able to delete directories. I was merely raising concerns with the change. The fact that ENSURE-DIRECTORIES-EXIST has no ENSURE-DIRECTORIES-DO-NOT-EXIST suggests to me that DELETE-FILE was intended all along to have that capability anyhow. I probably should have stated this in my first email.</div><div><br></div><div>Thanks for the link to the term file. It is interesting that the "Arguments and Values" section for PROBE-FILE and DELETE-FILE specify pathname designator [1] rather than file.</div><div>This gives the impression that you could delete/probe a pathname host or device. It is not until the description do you see any mention of the term file. I guess now it is down to what you consider to be "in" a file system. </div><div><br></div><div>Ah, the fun.</div><div><br></div><div>Mark</div><div><br></div><div>[1] <a href="http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_p.htm#pathname_designator">http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_p.htm#pathname_designator</a></div><div><br></div><div><br></div><div>This excursion has lead to the discovery of ENOUGH-NAMESTRING, something I have always done by hand. Thank you!</div></div></div></div></body></html>