[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: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] Maxima load("aaa/bbb") in GCL |
Date: |
25 Jun 2002 21:12:30 -0400 |
Hi Vadim!
"Vadim V. Zhytnikov" <address@hidden> writes:
> 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.
>
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.
> 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
current.
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.)
Take care,
> Any ideas?
>
> Vadim
>
>
>
>
>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah