[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