[asdf-devel] patch for component-relative-pathname

[james anderson]

a question:

On 2010-02-22, at 00:46 , Robert Goldman wrote:

> On 2/19/10 Feb 19 -2:19 PM, Faré wrote:
>>> 2.  SPLIT-PATH-STRING --- this is the one I think might need a  
>>> ticket.
>>> I confess I'm bamboozled by this one.  It's called on (component- 
>>> name
>>> component), not on a pathname.  Can you explain why the COMPONENT- 
>>> NAME
>>> would end up being a string that looks like a pathname?
>>>
>>> This SPLIT-PATH-STRING stuff looks like a relatively recent gwking
>>> addition (if I understand the output of git blame correctly).  I  
>>> don't
>>> see what use case it was introduced for.  Anyone else have a  
>>> clue?  I
>>> see this docstring for component-name:
>>>
>> gwking might have done the checkin, but I am the one who wrote the  
>> code at ITA,
>> where we wanted to be able to use "foo/bar" as the name of a  
>> component,
>> instead of having all those ugly :pathname #.(make-pathname ...)
>> ALL OVER THE DAMN PLACE for hundreds of components.
>>
>>> "Component name: designator for a string composed of portable  
>>> pathname
>>> characters"
>>>
>>> but I have never seen at component-name that was anything other  
>>> than a
>>> simple name, never something with directory separators.  Is this  
>>> ever
>>> used in the wild?  Or was this something that was added in an  
>>> excess of
>>> enthusiasm and that should just be killed (like the undocumented
>>> tripartite FEATURE form)?
>>>
>> Yes, we use it a lot at ITA, and ASDF-DEPENDENCY-GROVEL
>> and XCVB's ASDF front-end and backend use it, too.
>>
>> This change is 100% backwards compatible, since the behavior  
>> before then was
>> "undefined" when the #\/ character appeared in a name.
>> Now it's defined and portable.
>
> OK, I'm interested in writing up the documentation, and have been
> thinking about how this is to be treated.  Some thoughts:
>
> 1.  SPLIT-PATH-STRING is not an ideal name.  SPLIT-PATH-STRING is / 
> not/
> used on paths, it is used on /names/ (in the ASDF sense of these  
> terms).
>  An unwary reader of this code might try to apply it to a pathname  
> (as I
> originally thought), where it could cause lossage because S-P-S  
> doesn't
> handle logical pathnames (or lots of other things about pathnames).
> Suggest that we rename this to something like NAME-TO-PATHNAME or
> NAME-PATHNAME-SPLIT.
>
> 2.  We should define in the grammar simple-names and structured names.
> Simple names have no "/" and structured names may have a slash.
>
> 3.  The period character should be forbidden in /both/ simple and
> structured names because of oddities with pathname types.
>
> 4.  Only simple names should be permitted in naming systems.
>
> 5.  For modules, I propose either:
>
>    5.1 Only simple names should be permitted in naming modules, or
>
>    5.2 The use of a structured name implicitly overrides the default
> relative pathname for modules.  [a test should go here!]
>
> On a related note, the grammar in the manual seems to suggest that a
> component can be just a string, which I don't believe that ASDF  
> supports.
>
> The grammar says:
>
> component-def  := simple-component-name
>                 | ( component-type name {option}* )
>
> But I don't believe SIMPLE-COMPONENT-NAME is actually supported.  I
> propose to squash this from the documentation, unless corrected.

why is this better than to leave names atomic and provide a standard  
syntax to parse component relative (sic) pathnames?