Re: [Gcl-devel] Re: delayed pathname.d patch

[Camm Maguire]

Greetings!  And thanks for following along!

"Bill Page" <address@hidden> writes:

> On Thursday, April 22, 2004 5:48 PM Mike Thomas wrote
> > 
> > Whether this patch is really the cause or it has just 
> > triggered the strange path behaviour seen in the Maxima
> > build I don't know, but the build now fails trying to
> > compile pcl/pcl_pkg.lsp because the C compiler is fed a
> > path with no device (C:) as follows:
> > 
> 
> In case you might sometimes get the feeling that no one
> else is watching your continuing dialogue with Camm towards
> the next GCL release,  I thought I would just say that I
> for one, find the detailed online "debugging by email"
> quite interesting (but challenging) reading. However I am
> gradually learning more about GCL. Thanks.
> 
> When you mentioned that you are seeing paths without the
> C: prefix in Windows, it reminded me that this was one of
> the things I struggled with while trying to get Axiom
> running on Windows. I came to the conclusion that there
> are several places - in Axiom at least - where file names
> are passed as symbols instead of strings. This seems to
> mean that sometimes the C: is misinterpreted as something
> like a (package?) name and not part of the file name or
> path. I don't know if this is the what is happening in
> this particular case, but it seems to be a general issue
> in windows that the C: syntax of file names precludes the
> use of symbols. Does this make sense?
> 

This is quite related, but not exactly the problem we face, to my
understanding.  The main issue appears to have been that many have
contributed to both GCL and GCL compiled programs over a long period
of time without either grasping or deciding to use common lisp
pathnames, which are an abstraction built into the language precisely
for circumstances such as these.  In particular, GCL has code
designating files directly by their 'namestring', i.e. a string by
which the underlying OS references the files.  By in large, such code
has been put in with the idea of working on unix-like  systems, where
GCL has the most experience and users, and where it works the best,
leaving little incentive for change.  Fully supporting our windows
port is providing this incentive for a pathname overhaul, but a
complete treatment will have to wait until 2.7.x.

The proper place for the 'c:' in windows pathnames is in the 'device'
component.  Filename strings starting with this form do produce a
device entry in the resulting pathname object when run through
parse-namestring and the like, but in many places, make-pathname and
or merge-pathnames is called without a proper device default.  I would
be most appreciative if some Windows user could let me know what
*DEFAULT-PATHNAME-DEFAULTS* is on their system.  We need also to
ensure that no code is placing this device string at the head of the
directory component of the pathname instead, as this will break quite
a bit of logic.  In fact, if the current pathname mangling bug were
reproducible, this is where I would look.

Using the pathname abstraction, it would be quite easy to support
backslashes as directory name separators too, I'd think, though what
utility this would provide at this point is questionable.

Symbols by default get a 'name' component which is a string usually
equal to what one would type into GCL to reference the symbol, except
being converted to upper case (at present).  One could get a symbol
with a symbol-name having a colon in the right place with something
like

(make-symbol "c:foo/bar")

#:|c:foo/bar|

>(symbol-name (make-symbol "c:foo/bar"))

"c:foo/bar"

>

but then one could not reference the symbol with the same syntax --
the reader would interpret the device as a package.  Several functions
can take either symbols or strings as arguments presupposing the
conventional interchangeability, coercing automatically to a pathname,
but here it obviously breaks down.  

What one really wants to pass as filename arguments is something like
(pathname "dir/file.ext").

I'm quite curious how axiom manages to "pass filenames as symbols" --
it would appear the origin of all file i/o would be in the form of
strings.

Take care,


> Regards,
> Bill Page.
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah