[armedbear-devel] translate-logical-pathname and :wild-inferiorsregression
evenson at panix.com
Wed Feb 3 13:51:41 UTC 2010
On 1/29/10 4:12 PM, Alan Ruttenberg wrote:
> On Fri, Jan 29, 2010 at 4:03 AM, Mark Evenson<evenson at panix.com> wrote:
>> On 1/18/10 4:51 PM, Alan Ruttenberg wrote:
>>> (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*"
>> Acknowledge and logged as [ticket 82].
Somehow, the more I learn about Pathnames, the less I understand.
First off, I think that the SETF on LOGICAL-PATHNAME-TRANSLATION should
never use the #P for its arguments as you had in your example:
(setf (logical-pathname-translations "ido")
because it doesn't do what you might expect, namely the
#p"IDO:IDO-CORE;**;*.*" is not interpreted as a logical pathname when
read by the SHARP_P reader. You end up with an Pathname whose NAME is
"IDO:IDO-CORE;**;*.*" and other components are nil. That this ever
worked in ABCL is mysterious. Based on a canvas of open source Lisps
available to me, SBCL, ECL, and CCL all signal errors on being input
this form, for a variety of differing reasons. clisp accepts the form,
but fails to record it as a logical pathname.
Second, refactoring your test case away from logical pathnames down to
the use to TRANSLATE-PATHNAME, I derive the following use of
TRANSLATE-PATHNAME to be equivalent to the behavior you want:
(translate-pathname "/immunology/" "/immunology/**/" "/usr/home/**")
which you want to output
but none of the other Lisps I checked (SBCL, ECL, CCL, and clisp) work
this way, they all return
I think they do this to avoid the case for which Thomas Russ reported a
(translate-pathname "/immunology/" "/immunology/**/"
as was the pre-r12283 ABCL behavior.
So, I am a bit confused on how to proceed. The behavior of
TRANSLATE-PATHNAME is implementation specific. From fuddling around
with the old implementation and the new one, I seem to be able to get
either behavior but not both and they seem logically incompatible but I
haven't proved that definitely to myself. Since the other CL
implementations exhibit the same behavior as current ABCL I need either
a) evidence that another Lisp works the way that Alan expects (and does
it then exhibit the same behavior that is a bug to Thomas Russ?) or b) a
clear semantics that I can implement that satisfy both uses.
Input kindly solicited from one and all.
"A screaming comes across the sky. It has happened before, but there
is nothing to compare to it now."
More information about the armedbear-devel