Isn't supplying :unspecific as the value of :type always to be avoided?
The CLHS says:
"Portable programs should not supply :unspecific for any component." [documentation for function MAKE-PATHNAME]
and in section 19.2.2.2.3 :UNSPECIFIC as a component value
"A conforming program must never unconditionally use a :unspecific as the value of a pathname component because such a value is not guaranteed to be permissible in all implementations."
So instead of supplying this for a couple of cases and then trying to avoid it for others, shouldn't we be avoiding it altogether?
I confess that I don't fully understand this issue, since it seems like the CLHS makes it clear that NIL is /not/ fully equivalent to :unspecific (since the latter is not "overwritten" in a merge), and yet tells us not to use the latter....
If anyone can clarify this, it would be great....
Best, r
On 15 March 2010 22:58, Robert Goldman rpgoldman@sift.info wrote:
Isn't supplying :unspecific as the value of :type always to be avoided?
The CLHS says:
"Portable programs should not supply :unspecific for any component." [documentation for function MAKE-PATHNAME]
and in section 19.2.2.2.3 :UNSPECIFIC as a component value
"A conforming program must never unconditionally use a :unspecific as the value of a pathname component because such a value is not guaranteed to be permissible in all implementations."
So instead of supplying this for a couple of cases and then trying to avoid it for others, shouldn't we be avoiding it altogether?
I confess that I don't fully understand this issue, since it seems like the CLHS makes it clear that NIL is /not/ fully equivalent to :unspecific (since the latter is not "overwritten" in a merge), and yet tells us not to use the latter....
If anyone can clarify this, it would be great....
Oops. I hadn't paid attention to this paragraph. Should we use :unspecific based on a whitelist of known-working implementations, or should we just avoid it altogether?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Artificial intelligence is what we don't know how to do yet — Alan Kay
On 3/15/10 Mar 15 -10:06 PM, Faré wrote:
On 15 March 2010 22:58, Robert Goldman rpgoldman@sift.info wrote:
Isn't supplying :unspecific as the value of :type always to be avoided?
The CLHS says:
"Portable programs should not supply :unspecific for any component." [documentation for function MAKE-PATHNAME]
and in section 19.2.2.2.3 :UNSPECIFIC as a component value
"A conforming program must never unconditionally use a :unspecific as the value of a pathname component because such a value is not guaranteed to be permissible in all implementations."
So instead of supplying this for a couple of cases and then trying to avoid it for others, shouldn't we be avoiding it altogether?
I confess that I don't fully understand this issue, since it seems like the CLHS makes it clear that NIL is /not/ fully equivalent to :unspecific (since the latter is not "overwritten" in a merge), and yet tells us not to use the latter....
If anyone can clarify this, it would be great....
Oops. I hadn't paid attention to this paragraph. 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.
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
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?
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).
Can you clarify?
thanks, r
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:
- 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).
- 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"
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:
- 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).
- 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"
On 2010-03-16, at 04:32 , Faré wrote:
[ ... ]
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.
past experience with pathname portability led to the proposed patch to the pathname merge operator to construct a contingent argument list to make-pathname. where no component is to be specified, none is passed to make-pathname. if the context is such that one does not need to block a default component, that tactic should be sufficient.
my recollection is that it worked for all tested implementations.
-
Faré -
james anderson -
Robert Goldman