From: Stephen Schleimer
Subject: Java implementation of Common Lisp
Date: 
Message-ID: <3A955A2A.76DFB414@cisco.com>
Folk,

I am looking for a public domain Java implementation of Common Lisp or
reasonable subset.

Any references appreciated.

Please at lease respond to me privately.

Thanks

-steve
From: Colin Walters
Subject: Re: Java implementation of Common Lisp
Date: 
Message-ID: <87y9uycwez.church.of.emacs@meta.verbum.org>
Stephen Schleimer <·······@cisco.com> writes:

> I am looking for a public domain Java implementation of Common Lisp
> or reasonable subset.

I think Per Bothner's "Kawa" has some support for Common Lisp.  I've
been meaning to look at it for a while.

<URL:http://www.gnu.org/software/kawa>

It's not public domain, but protected by the GNU GPL.
From: Johannes Beck
Subject: Re: Java implementation of Common Lisp
Date: 
Message-ID: <3A96CEEE.BB848EA6@arcormail.de>
Colin Walters wrote:
> 
> Stephen Schleimer <·······@cisco.com> writes:
> 
> > I am looking for a public domain Java implementation of Common Lisp
> > or reasonable subset.

You can use any large application written in Java to get what you're
looking for, because of Greenspun's Tenth Rule of Programming: 
"Any sufficiently complicated C or Fortran program contains an ad-hoc,
informally-specified bug-ridden slow implementation of half of Common
Lisp." 

The law is true for Java too.

--
joe - still on the search of enlightened laziness
From: Per Bothner
Subject: Re: Java implementation of Common Lisp
Date: 
Message-ID: <m2ofvo1rfe.fsf@kelso.bothner.com>
Colin Walters <·········@cis.ohio-state.edu> writes:

> I think Per Bothner's "Kawa" has some support for Common Lisp.  I've
> been meaning to look at it for a while.
> 
> <URL:http://www.gnu.org/software/kawa>

Recently, I've been working re-doing the Kawa parser, so it conforms
closer to the Common Lisp reader algorithm, including using
read-tables.  (This is all written in Java, but it uses suitable data
structures, so it should be easy writing the standard CL functions as
wrappers on the Java methods.)  Don't know when it will be working
well enough to check in, though.  The parser stuff is basically done,
but the code is intertwined with other changes I'm making, including
changes to the support for 2-Lisp (i.e. separate data and function
namespaces).  The existing code sort-of-works, but isn't really
extensible to using packages.

Nothing big to tell here - just letting people know that I am
plugging away at improving the Common Lisp support in Kawa
(along with other projects).
-- 
	--Per Bothner
···@bothner.com   http://www.bothner.com/~per/
From: David Bakhash
Subject: Re: Java implementation of Common Lisp
Date: 
Message-ID: <m3itm2372l.fsf@cadet.dsl.speakeasy.net>
Stephen Schleimer <·······@cisco.com> writes:

> I am looking for a public domain Java implementation of Common Lisp
> or reasonable subset.

just doing a little search on freshmeat:

http://sourceforge.net/projects/jlisp/

dave
From: Mike McDonald
Subject: Re: Java implementation of Common Lisp
Date: 
Message-ID: <aHkl6.777$Vf.27903@typhoon.aracnet.com>
In article <··············@cadet.dsl.speakeasy.net>,
	David Bakhash <·····@alum.mit.edu> writes:
> Stephen Schleimer <·······@cisco.com> writes:
> 
>> I am looking for a public domain Java implementation of Common Lisp
>> or reasonable subset.
> 
> just doing a little search on freshmeat:
> 
> http://sourceforge.net/projects/jlisp/
> 
> dave

  Doing a little more research and you'd find that it's an empty project
template.

  The whole idea of a CL running on the JVM just makes my skin crawl. And we
keep wondering why everyone thinks CL is slow. How come no one asks for a C++
on JVM?

  Mike McDonald
  ·······@mikemac.com
From: Frank A. Adrian
Subject: Re: Java implementation of Common Lisp
Date: 
Message-ID: <eQml6.4542$hA1.650342@news.uswest.net>
"Mike McDonald" <·······@mikemac.com> wrote in message
·······················@typhoon.aracnet.com...
>   The whole idea of a CL running on the JVM just makes my skin crawl. And
we
> keep wondering why everyone thinks CL is slow. How come no one asks for a
C++
> on JVM?

Because they know that simulating the memory and pointers would be even
slower for a JC++ than would be a decent implementation of Lisp on the JVM.
By the time you got exceptions right and had enough structure to handle
lexical variables properly, you'd be running an interpreter anyway and the
thing would be dog slow.  Not to mention the hideous penalty you'd pay for
any arithmetic.  All-in-all, an experiment that probably should not be
attempted except for a lark.

faa
From: Espen Vestre
Subject: Re: Java implementation of Common Lisp
Date: 
Message-ID: <w6snl5u89x.fsf@wallace.ws.nextra.no>
·······@mikemac.com (Mike McDonald) writes:

>   The whole idea of a CL running on the JVM just makes my skin crawl. And we
> keep wondering why everyone thinks CL is slow. How come no one asks for a C++
> on JVM?

people actually *use* Python running on the JVM...
-- 
  (espen)
From: Per Bothner
Subject: Re: Java implementation of Common Lisp
Date: 
Message-ID: <m2itlw1r4g.fsf@kelso.bothner.com>
·······@mikemac.com (Mike McDonald) writes:

>   The whole idea of a CL running on the JVM just makes my skin crawl. And we
> keep wondering why everyone thinks CL is slow. How come no one asks for a C++
> on JVM?

First of all, the idea (well, my idea) is to *compile* Common Lisp
into Java bytecodes.  Thus you avoid the double interpertation
overhead.  Second, many JVMs include "just-in-time-compilation"
- i.e. the bytecode is compiled in-the-fly to native code.  Thus
because of all the engineering being put into JVMs these days,
it is quite plausible that CL running on JVM might actually be
quite fast.

Slightly related note:  I have been working on compiling Kawa,
including the parts written in Scheme and Common Lisp, into
native machine code, using Gcj the Gcc-based Java compiler.
I hope to be able to check that in (to CVS) soon.
-- 
	--Per Bothner
···@bothner.com   http://www.bothner.com/~per/
comp.lang.lisp / 2001 / feb