[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Maxima load("aaa/bbb") in GCL
From: |
Vadim V. Zhytnikov |
Subject: |
[Gcl-devel] Maxima load("aaa/bbb") in GCL |
Date: |
Sun, 23 Jun 2002 18:47:18 +0300 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.0.0) Gecko/20020526 |
Hi!
Recently it was observed that Maxima command
load("aaa/bbb");
doesn't work in GCL Maxima.
The problem comes to Common Lisp function
merge-pathnames. On all CL implementations
including GCL
(merge-pathnames p#"fff" p#"/aaa/bbb/###.mac")
gives
/aaa/bbb/fff.mac
But for
(merge-pathnames p#"ccc/fff" p#"/aaa/bbb/###.mac")
results differ. Cmucl and clisp produce
/aaa/bbb/ccc/fff.mac
while GCL gives
/ccc/fff.mac
The point is that GCL and ANSI compliant Lisp
implementations treat "ccc/fff" in different
fashion. The major trouble is that GCL doesn't
distinguish relative and absolute path names.
GCL:
(pathname-directory "ccc/fff") -> ( "ccc" )
CLISP and CMUCL:
(pathname-directory "ccc/fff") -> ( :relative "ccc" )
(pathname-directory "/ccc/fff") -> ( :absolute "ccc" )
So GCL always treats "ccc/fff" as an absolute
pathname. I don't know whether this is CLtL1 compliant
or not (I don't have CLtL1) but it is certainly not ANSI
compliant. Unfortunately there is no easy way to fix
the problem since introducing :relative, :absolute keywords
affects other pathname related CL functions.
If we are going to bring GCL pathname behavior to
ANSI standard the we face serious problem.
If previous behavior was CLtL1 compliant (was it?)
when our modification will break such a compliance.
Shall we discard CLtL1 compliance?
It seems that this is inevitable if we are driving
toward ANSI CL. When?
Any ideas?
Vadim
- [Gcl-devel] Maxima load("aaa/bbb") in GCL,
Vadim V. Zhytnikov <=