[Ecls-list] patch for namestring

[Dustin Long]

Well I noticed that (make-pathname :name "." :type nil) is interpreted 
as #p"." since a type of nil is interpreted as having no type, whereas 
(make-pathname :name "." :type "") is interpreted as #p".." since type 
is non-nil, so the namestring-ing generates "..", due to the fact that 
the name is a string, therefore the "fullname" must be a "filename" + 
dot + "typename". But it seems to me, that if a type is empty (a 
zero-length string) it should be treated as though the type is a nil 
(non-existant). This would result in, in my interpretation:
(make-pathname :name "bleh" :type "") => #p"bleh"
as opposed to the current ecl's result of:
(make-pathname :name "bleh" :type "") => #p"bleh."
The problem seems to be more in printing (and converting to native) 
pathnames, than in parsing. Really, is there any significant difference 
in a (make-pathname) being giving a type of nil versus a string of ""? 
Both are parsed the same way, and both yield the same results for any 
(pathname-*) function that can be applied (including the (pathname-type) 
test cases that you included). The real difference exists not in the 
construction of the pathname itself, but rather in a conversion back to 
a string (in which case the current version of ecl violates the cl 
standard in the later part of section 23.1.6 [referencing the 2nd 
edition] (quote: "a valid namestring cannot necessarily be constructed 
simply by concatenating some of the three shorter string in order", this 
is actually happening in the code of "ecl_namestring", which my code 
patches at line 908), and also differs from clisp ). More of less, my 
patch makes
(namestring (make-pathname :name "." :type "")) => "."
(namestring (make-pathname :name "." :type nil)) => "."
whereas before
(namestring (make-pathname :name "." :type "")) => ".." ; link to up one 
directory
(namestring (make-pathname :name "." :type nil)) => "." ; current directory

If you disagree with this interpretation, please let me know. I would 
very much like to solve this issue.

Thanks,
Dustin


Juan Jose Garcia-Ripoll wrote:
> 2006/10/8, Dustin Long <dlong at stevens.edu>:
>   
>> This attached patch fixes (namestring) which previously appended an
>> extra period to pathnames with a non-nil, yet blank, type
>>     
>
> I am quite sure this is not the solution. There is a current problem
> with the parsing of "." which is interpreted has having type = ""
> intead of NIL, as it probably should be.
>
>   
>> (pathname-name ".")
>>     
> "."
>   
>> (pathname-type ".")
>>     
> ""
>   
>> (pathname-type "foo")
>>     
> NIL
>
>