[asdf-devel] never ending component relative pathnames [2]

[Robert Goldman]

On 3/9/10 Mar 9 -9:46 PM, Faré wrote:
>>> b- when the source-file-type of a component is a string, then it will
>>> be the type, and the last /-separated component of the string provides
>>> the name.
>>
>> This case worries me.  It seems to require that every system definer
>> have a strongish sense of the internals of ASDF, and will give odd
>> results when someone writes
>>
>> (:cl-source-file "foo.lisp")
>>
>> ASDF will want "foo.lisp.lisp".
>>
>> I know /why/ you got to this, and if you think about ASDF "from the
>> inside" it makes sense, but "from the outside" I don't think it makes sense.
>>
>> Would it be so bad to change this to
>>
>> "when the source-file-type of a component is a string, then a
>> component-name containing a period will cause ASDF to emit an error."
>>
>> This will cause the vast majority of simple cases to behave sensibly,
>> IMO.  It has the effect of making it hard to put a period in a file
>> name.  But since embedding periods in filenames in the CL pathname
>> systems is problematic, I'd prefer making the user specifically indicate
>> that s/he is good and bloody sure s/he wants that period to be part of
>> the :name component by imposing some cumbersome quoting requirement.
>> Perhaps something like "fooYESIBLOODYWELLMEANIT.bar" ;-)
>>
> I'd vote against this rule you propose, because
> 
> 1- I am in charge of building a large system, where some components
> have names such as foo-V1.1/ or bar/baz-V1.200.lisp that reflect the
> fact that we must deal with compatibility with various versioned
> protocols. I'd rather not go back to having to magically generate
> pathnames for them when portable names were previously possible.
> 
> 2- for backwards compatibility with existing system files, the type
> must be optional.
> 
> 3- for aesthetic reasons, I find that it's nicer if I don't have to
> mysteriously do "bar/baz" but "bar/baz-V1.200.lisp". I feel that the
> rule ".lisp is always added to the filename" is simpler and easier for
> newcomers to understand than the rule ".lisp is added to the filename
> iff there isn't a dot in the name already".

I think we're on the same page about that, but it seems to me that the
rule in your email earlier was ".lisp" is added to the filename if there
isn't a dot in the name already and if the filetype is null.

I thought your proposal was that if the file was a cl-source file (and
would get ".lisp" added because of source-file-type), then if you put a
".lisp" in the filename, you would get TWO copies --- ".lisp.lisp"
because the .lisp in the filename would not be interpreted as a type,
but as a part of the name proper.  I was unhappy with that because it
seemed like a complex dependency on something that's invisible to the
system definer (viz. the component-file-type method).  But maybe I
misread your original email?

Thanks,
r

> 
> [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
> Trying to make bits uncopyable is like trying to make water not wet. The
> sooner people accept this, and build business models that take this into
> account, the sooner people will start making money again. — Bruce Schneier