On Mar 18, 2007, at 6:04 AM, Lex Spoon wrote:

> Howard Stearns <hstearns at wisc.edu> writes:
>> Back when I believed in files (!), I thought the ANSI Common Lisp  
>> spec on
>> pathnames was as powerful as it needed to be, and no more.
>
> Thanks for the pointer, btw.

No problem.

> I happen to have been looking for good
> file and filename specs over the last few months, with a mind to
> figuring out what good wrappers would look like for the Java file
> classes.  Eclipse Lisp is also interesting in this regard, of course;
> I presume it uses only the JVM's file primitives, and no native
> library to get more?

I do not think Eclipse Common Lisp helps you in providing any clues  
for how to implement the primitives using Java. It only helps in  
defining a known-to-be-sufficient set of high-level operations.

Eclipse Common Lisp was (past tense) a Lisp - in - C, such that the  
compiler generated human readable C. C could call Lisp in natural  
way, and vice versa.

It predated the Eclipse IDE and had nothing to do with it. (It also  
had nothing to do with the Eclipse C++ Rete engine.)

As it happens, the compiler was designed to also be able to also  
generate JVM byte codes or even human readable Java.  This would have  
worked as you imagined above. However, that would have also required  
two projects I never started:

  1. A rationalization of the Common Lisp and Java class hierarchies.  
If I recall, it was theoretically "mostly" possible, by interposing  
Java classes between the Lisp classes and vice versa. But if I recall  
correctly there were a couple of inversions.  This is, in general,  
necessary for the next step in order to the arguments to the high- 
level operations to be passed directly the the primitive operations  
without having to wrap or convert them. (Although it's much easier in  
a limited domain like pathname operations.)

  2. A reimplementation of some of the primitive operations. For  
example, the file operations were implemented using a platform- 
neutral wrapper extensions of the Posix operations. (The pure Posix  
stuff didn't provide everything needed.)  These would have been  
changed to using the JVM primitives, for which I would have written  
new Posix wrappers when using the C back end.  The idea was that the  
Common Lisp library source would not be conditionalized for different  
back-ends, nor would the generated Java or C code be conditionalized.  
Only the hand-written primitive stuff it called might be  
conditionalized.  This would NOT have allowed C and Java to talk to  
each other, nor would it have allowed another target back-end to be  
added, but that was never the idea.

There was a project at BBN/GTE-Internetworking in the late 90's to do  
something like this (with Scheme maybe), but I don't remember.