[names-and-paths-devel] Re: Spaces in logical pathnames

Marco Antoniotti marcoxa at cs.nyu.edu
Tue Jun 24 06:53:47 UTC 2008


On Jun 18, 2008, at 17:30 , Chun Tian (binghe) wrote:

>
> Hi, Marco (or Macro?)

Macro in the Lisp world, Marco elsewhere :)

> I think the problem with CL pathname is different from others, like  
> networking, GUI... Though packages like CL-FAD already done big  
> help as an addition to exist pathname interface, I don't think a  
> portable pathname interface itself is necessary.

It is your opinion.  I think a portable pathname *specification* is  
necessary.

> As far as I see, the biggest problem of CL pathname is that every  
> CL implementor has his own opinion on how to implement a "right"  
> pathname spec of CL standard.

The problem is that the pathname spec is way too underspecified and  
concocted at a time when there were things like ITS and TOPS-10-20-42.

> We, CL user, also have our own opinion. Fortunately we can talk  
> about this topic directly to all CL implementors as we wish on  
> mailing list, and keep talking to find out a common knowledge about  
> CL pathname. At present, I think I have to use the most common part  
> of pathname (on the way all CL supported), and just wait people who  
> can make them better to judge whether to get it slightly changed to  
> fit more people's tastes.

Ok.  But I do not understand.  Is talking about a common  
specification a good thing or a bad thing?  I am not saying it is  
immediately useful, but somohow, somewhere, the issues should to be  
discussed.  Talking separatedly to the implementors is not IMHO very  
fruitful.  I think that users and implementors discussing this issue  
together is a better way of proceeding.

Once there is some consensus, then you can go ahead and write a CDR.

But the bottom line stands.

	(parse-namestring ".cshrc") ; On a UN*X filesystem

should return the "same" thing on every implementation.  (Note: I  
don't care what, just the same, possibly 42 :) ).

Cheers
--
Marco


PS.  Sorry.  I think this is a little OT.  Please feel free to move  
the discussion on NAMES-AND-PATHS-DEVEL.






>
> Regards,
>
> Chun Tian (binghe)
>
>>
>> Very interesting discussion.
>>
>> Do you all know that there is a venue for discussing all these  
>> vexing issues and try (at least *try*) to come up with a solution?
>>
>> http://common-lisp.net/project/names-and-paths
>>
>> Please join the mailing lists there and let's get to work.
>>
>>
>> Cheers
>> --
>> Marco
>>
>> PS.  What is there is a *start*.  Nothing more.  One missing part  
>> is the recognition of different File Systems.
>>
>>
>>
>>
>> On Jun 18, 2008, at 01:52 , Chun Tian (binghe) wrote:
>>
>>>
>>>>>
>>>> Thanks, but that's not the solution I'm looking for. Yes, using  
>>>> spaces in pathnames is not portable to other CL systems, but it  
>>>> is portable among all current OSes that matter. So I think CL  
>>>> systems should allow it. I think using a specific logical  
>>>> pathname translation for each folder or file that has a space in  
>>>> the name is pretty ugly, I'd rather give up using spaces. I  
>>>> still hope there is a solution to allow it in LW, what else  
>>>> could the system::*logical-pathname-allow-spaces-p* be intended  
>>>> for?
>>>
>>> Hi,
>>>
>>> In old Symbolics time, logical-pathnames do can have spaces (I  
>>> think so by reading some old documents), but like this:
>>>
>>> #p"HOME:ASDF;PACKAGES;"
>>> #p"HOME: ASDF; PACKAGES;"
>>>
>>> When I saw system::*logical-pathname-allow-spaces-p*, I just  
>>> thought it's a switch to open above syntax, but unfortunately not...
>>>
>>> P.S. I think it's a big Challenge for modern CL systems to detect  
>>> whether a pathname string/object is a Logical-Pathname, and do  
>>> the other parsing job, but obviously enable spaces in logical- 
>>> pathname wouldn't cause much different meanings.
>>>
>>> Regards,
>>>
>>> Chun Tian (binghe)
>>>
>>>>
>>>>
>>>> Thanks,
>>>> Octav
>>>>
>>>
>>
>> --
>> Marco Antoniotti
>>
>>
>

--
Marco Antoniotti





More information about the names-and-paths-devel mailing list