[Openmcl-devel] Best practice for writing a loader (def-pathname blues)

Gary Byers gb at clozure.com
Mon Jan 16 03:29:53 PST 2006



On Mon, 16 Jan 2006, Peter Braroe wrote:

> Hi all!
>
> Thus is a oldbie post: I am trying to write a loader for a small project to
> work. I looked at some old code (written for Allegro CL 1.22! :-) that uses:
>

There was a period (in the late 80s) where what is now known known as MCL
was marketed as "Macintosh Allegro Common Lisp", though that never had
anything to do with Franz's Allegro CL product.  Eventually, the people
who thought that this made some sense realized that it didn't; I assume
that the old code you was "MACL"-specifoc.

>
> (def-logical-pathname "path" "Machintosh HD:MyDir")

This would have also been in the timeframe before ANSI CL added logical
pathnames.  MACL/MCL offered a simpler facility in those days; despite
the similar name, it had little to do with CL logical pathnames.

MACL also used (and, AFAIK, MCL still uses) HFS-based syntax to refer
to physical pathnames (e.g, pathname components separated by colons,
with a physical volume name as the first component of an absolute
pathname.)  OpenMCL uses Unix/POSIX syntax, where forward slashes
separate pathname components and an absolute pathname starts with
a forward slash.  If the OSX boot volume was named "Macintosh HD",
the absolute pathname of the MyDir subdirectory of the volume would
be "/MyDir/".


>
> And then
>
> (load "path;myfile")
>
> However this does not seem to work these days!
>

I doubt if it's worked since about 1991 or 1992.

> Question: What is the correct "best practice" way to write a loader today?
> Anyone have some elegant example code out there?
>
> I found some uses of (make-pathname ... ) but is that the way to go?

ANSI CL's logical pathnames are both more powerful/flexible than the old
MCL facility was and more complicated.   The typical idiom involves 
defining a "logical host" and defining translation rules which map
logical pathnames that have that host component to physical pathnames.
For example:

? (setf (logical-pathname-translations "path")
         '((#p"path:**;*.*" #p"/MyDir/**;*.*")))

This allows (for instance) the logical pathname

#p"path:subdir;foo.lisp"

to be used to refer to the file #p/MyDir/subdir/foo.lisp".

>
> The make-pathname command seems to stipulate that one defines the filetype
> also and what if I want to load other files containing data from the same
> directory - do I have to define two pathnames then?
>
> And what about packages - do I need to define which package a file belongs
> to in every file (like java)?
>
> And if I use packages do I always need to do export/use-package and such to
> be able to call my functions(methods)
>
> Hope this makes sense to someone and that this is not too annoyingly
> obvious!
>
> It's always amusing too see when doing something new that the difficult
> stuff is best documented and the easy big picture stuff (that one always is
> clueless about) is hard to find answers too!

There are good Common Lisp tutorials freely available.

See (for example):

<http://www.paulgraham.com/onlisp.html>

<http://www.alu.org/alu/res-lisp-education>

and


<http://cybertiggyr.com/gene/pathnames-0/>

OpenMCL intentionally deviates from the ANSI CL spec in one
pathname-related way; the spec says (for instance) that logical
pathname components are maintained in upper case and (usually) mapped
to the "preferred case" of the underlying filesystem on translation.
I don't know of any filesystems in widespread use today for which the
concept of "preferred case" has meaning, and there are certainly
filesystems in widespread use today which are case-sensitive; OpenMCL
ordinarily preserves the case of logical logical pathname components
during both logical pathname parsing and translation.

>
> Thanks beforehand all!
>
> /Peter
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>



More information about the Openmcl-devel mailing list