[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Maxima load("aaa/bbb") in GCL

From: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] Maxima load("aaa/bbb") in GCL
Date: Wed, 26 Jun 2002 20:59:35 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.0.0) Gecko/20020526

Camm Maguire пишет:
Hi Vadim!

"Vadim V. Zhytnikov" <address@hidden> writes:


Recently it was observed that Maxima command
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")
But for
  (merge-pathnames p#"ccc/fff" p#"/aaa/bbb/###.mac")
results differ. Cmucl and clisp produce
while GCL gives

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.
  (pathname-directory "ccc/fff") -> ( "ccc" )
  (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.

OK, I don't understand the last sentence fully.  can you spell out
what will/might break if we just make the gcl behavior ansi compilant?
Should not be difficult -- I just don't want to break what we have
working now.

Well, I just mean that there is dosen of various pathname related functions in CL standard. If we are going to change one of them
then all other must be changen accordingly.
The load("aaa/bbb"); problem in gcl doesn't amount to
fixing one wrong function.  We heve to introduce new notion,
change internal representation of lisp pathnames #p"...",
and modify all related 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?

I think that

1) Where the 3 known large existing open-source projects that use gcl
   are known not to break with the change, go ansi and discard

2) Where the old functionality is known to be relied on, make some
   global variable that can be set at compile time to restore the old
   behavior, and make ansi the default.  (I intend to make the ansi
   build you've put together the default as well as soon as we can
   chase down the 'when' issue, the serror issues, and the lack of gdb
   symbols for debugging in the new images.)

Fine, I'll try all my best to help with all these problems. But I'm oftenly run out of spare time :-(

Take care,

Any ideas?


Gcl-devel mailing list

reply via email to

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