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

[Camm Maguire]

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