gcl-devel
[Top][All Lists]
Advanced

[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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]