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

[Vadim V. Zhytnikov]

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. 

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
>    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.)
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?
> >
> > Vadim
> >
> >
> >
> >
> >
> > _______________________________________________
> > Gcl-devel mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/gcl-devel