[asdf-devel] Question about use of :unspecific

[Robert Goldman]

Thanks for the clear discussion.  Maybe best to just return NIL for type
always then.

This has the potential added advantage that if it causes bugs, the bugs
will /also/ appear on SBCL, which seems like the most tested configuration!

Best,
r


On 3/15/10 Mar 15 -10:32 PM, Faré wrote:
>>> Should we use :unspecific based on a whitelist of known-working
>>> implementations, or should we just avoid it altogether?
>>
>> Either of those seems OK to me.  I think a blacklist is probably wrong,
>> just because it's too hard to update.
>>
> Agreed.
> 
>> OTOH, I don't really understand the motivation in two places here:
>>
>> 1.  I don't understand the rationale for the prohibition in the CLHS
>> (probably someone from one of the implementation groups can say
>> something about this) and
>>
> For backwards-compatibility probably, the CLHS allowed implementations
> to NOT implement :unspecific. Some indeed don't (CLISP and ABCL at least).
> 
>> 2. I don't know the rationale for returning it from SPLIT-NAME-TYPE.  I
>> understand that :unspecific has different behavior under merging (which
>> is why I don't understand why it's forbidden), so it seems like one of
>> two things should be the case:
>>
>>   a.  if you can return NIL for clisp and ABCL, it should be possible
>> to return NIL for all the other implementations or
>>
>>   b.  if returning :unspecific is necessary for some implementations,
>> shouldn't returning NIL on CLISP And ABCL fail?
>>
> I think that in practice, the parent pathname always has NIL in its type,
> so that there is no difference between the merged pathname having type
> NIL or :UNSPECIFIC.
> 
>> It seems like either these pathnames are never subjected to
>> MERGE-PATHNAMES, in which case we can just always return NIL, or they
>> /are/ sometimes subjected to MERGE-PATHNAMES, in which case sometimes
>> the use of NIL instead of :unspecific will cause oddities (unless the
>> default type is always empty).
>>
> Using :UNSPECIFIC seemed like it might produce more robust code.
> But now that I realize the unportability, I don't care as much.
> 
> SBCL, CCL and LispWorks all pass janderson's tests just as well with
> either NIL or :UNSPECIFIC. Haven't counted failures in other implementations.
> 
> [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
> Director is a misnomer. You're a hoper. You put all these people together and
> you hope it all works out.  — Frank Oz, director of "Dirty Rotten Scoundrels"