Lisp on the JVM
Rainer Joswig
Daniel Weinreb
> http://www.is-research.de/info/vmlanguages/lisp.html
>
> cough
>
This is a well-done and very extensive list. I didn't know there
were so many Lisp implementations on the Java Virtual Machine. Of
course, he's including a broad
range of languages in the Lisp/Scheme family, but
that's fine. His descriptions, in cases where
I know the language, are good.
kod...@eurogaran.com
Thomas Munro
> Does anyone know of any working implementations on the M$ C# engine?
Common Larceny - http://www.ccs.neu.edu/home/will/Larceny/
Pascal Costanza
Things could actually improve further on JVM with Java 7. I have taken a
brief look at the new invokedynamic bytecode, and it seems that
everything that's necessary for supporting Lisp functions, including
full generic functions, is there.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Chun Tian (binghe)
> Does anyone know of any working implementations on the M$ C# engine?
http://code.google.com/p/jrm-code-project/
Dig into its SVN repository, you'll find a Lisp written in C# and
source code of the LMI K-Machine.
Slobodan Blazeski
is only an optional backend, are people using it?). And I'm quit
suspicious of how serious are this implementations. It would be good
to differentiate real implementations from pet langauges with little
bit more then car,cdr and no useful functionality. Something like SISC
description "The entire R5RS Scheme standard is supported." would be
very helpful.
bobi
Marek Kubica
kod...@eurogaran.com wrote:
> Does anyone know of any working implementations on the M$ C# engine?
IronScheme <http://www.codeplex.com/IronScheme>
regards,
Marek
Pascal J. Bourguignon
> http://www.is-research.de/info/vmlanguages/lisp.html
>
> cough
Well, one thing JVM has for it, is that there's no newLISP
implementation on it...
--
__Pascal Bourguignon__
Michael Weber
> Things could actually improve further on JVM with Java 7. I have taken a
> brief look at the new invokedynamic bytecode, and it seems that
> everything that's necessary for supporting Lisp functions, including
> full generic functions, is there.
Well, you did not outline which problems need to be solved and how
invokedynamic helps, but I suspect it all boils down to performance,
right?
I am saying that because having GFs in Java is no problem as far as I
can see, if you allow two catches:
1. everything gets boxed
2. function arguments end up in an Object[] array (this is partly also
because of &rest, &optional and &key)
(sorry for the drive-by posting, no time to expand on this now)
Pascal Costanza
What you can do is to represent a generic function as an instance of
some Java class with a particular invocation method. However, one very
important optimization in CLOS is that you can replace the invocation
method over time, so that whenever you add or remove a method, you can
put an optimized "discriminating" function there that knows about all
existing methods.
The design for invokedynamic seems to allow such dynamic patching of the
invocation method, which should be a good basis for achieving
competitive performance.
Kaz Kylheku
> Daniel Weinreb wrote:
>> Rainer Joswig wrote:
>>> http://www.is-research.de/info/vmlanguages/lisp.html
>>>
>>> cough
>>>
>>
>> This is a well-done and very extensive list. I didn't know there
>> were so many Lisp implementations on the Java Virtual Machine. Of
>> course, he's including a broad
>> range of languages in the Lisp/Scheme family, but
>> that's fine. His descriptions, in cases where
>> I know the language, are good.
>
> Things could actually improve further on JVM with Java 7. I have taken a
The JVM is obsolete, because real machine virtualization has become
commonplace.
Why would I run some poor quality fake virtual machine when I can virtualize an
entire operating system, that has MMU based memory management, its own TCP/IP
stack, its own accurate process and thread scheduler, etc.
In the real virtual machine, I can run any programming languages I want.
No representational model is shoved down my throat about how code should
be packaged and what it can or cannot do.
Pascal Costanza
JVM technology has come up with pretty impressive dynamic compilation
techniques and very advanced garbage collectors, to name just two
examples. It can be interesting to reuse such technology.
Robert Dodier
wrote:
> Good, but I don't see any *known* name, except ABCL & Bigloo (which
> is only an optional backend, are people using it?). And I'm quit
> suspicious of how serious are this implementations.
Well, let me take this opportunity to toot ABCL's horn here.
After a long period of inactivity, ABCL (with new maintainers) is
getting pretty close to a full implementation of the CL spec,
and there are several people active in the project. So I'll
encourage any bored Lispniks to help them out.
My own interest in ABCL is that it provides a way to run Maxima
on JVM. It doesn't quite work yet; Maxima is a rather idiosyncratic
program, and trying to run it has exposed several bugs in ABCL.
To their credit the ABCL team has fixed most of the problems but
there is still work to do.
FWIW
Robert Dodier
Alexander Schreiber
*sigh*
You very obviously don't understand the different problems that language
VMs (like the JVM) and system virtualisation (Xen, VMWare, ...) are
trying to solve. They are very different beasts.
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Marek Kubica
Kaz Kylheku <kkyl...@gmail.com> wrote:
> The JVM is obsolete, because real machine virtualization has become
> commonplace.
Virtualization does not help at all when you are trying to use foreign
language libraries like it is possible and common in Scala or Clojure
for example.
And virtualization doesn't help you when you have native code for MIPS
and want to run it on ARM. You'd need to emulate and not to virtualize
and that's way to slow to be usable.
regards,
Marek
Mark Wooding
> JVM technology has come up with pretty impressive dynamic compilation
> techniques and very advanced garbage collectors, to name just two
> examples. It can be interesting to reuse such technology.
Also, a higher level VM makes it easier for multiple languages to
cooperate properly. Does anyone really enjoy writing CFFI wrappers for
C libraries? It's even less pleasant if the library you want to use is
in, say Python.
It's not as if one would actually need a lot of translation layers and
whatnot if Python and Lisp semantics could share a common substrate: the
semantics of various numbers and functions and so on are pretty similar.
(There's a mismatch over whether strings are mutable, for example, but
that's not a really big deal.) But because Python uses a completely
different runtime system from Lisp implementations, one needs to mess
about at the C level[1] to get them talking, even after you've squashed
them into the same address space together.
[1] You can use CFFI in Lisp and `ctypes' in Python to avoid actually
writing any real C, but that doesn't mean that you can avoid having
to work at that level.
-- [mdw]
Mark Wooding
> Well, let me take this opportunity to toot ABCL's horn here.
> After a long period of inactivity, ABCL (with new maintainers) is
> getting pretty close to a full implementation of the CL spec,
This is excellent news. I've not used ABCL very much, but it worked
well enough (just about) a while ago for me to be very grateful.
(I wanted to bash together a simple GUI thing that would work on
Windows, without me having to actually touch a Windows machine for more
than about five minutes. I messed with Mono for a bit before deciding
that System.Windows.Forms was just too awful; Python and (say) wxWindows
required too much installing weird stuff at the far end. I gave up and
used Swing, but actually writing Java was far too much like pulling my
own fingernails out with rusty pliers. ABCL came to my rescue!
If anyone cares, I have some fancy functions for doing Java method and
constructor overload resolution at run-time based on the dynamic
argument types.)
-- [mdw]
Matthias Buelow
> Why would I run some poor quality fake virtual machine when I can virtualize an
> entire operating system, that has MMU based memory management, its own TCP/IP
> stack, its own accurate process and thread scheduler, etc.
What has one got to do with the other?
Want to run a separate OS for every process?
How about portability to different architectures (the "write once, run
everywhere" [yes, I know...])?
jos...@corporate-world.lisp.de
Not every process. But if you look at some companies, they are running
each app in a different virtualized OS on blade servers.
alien_guy
> Pascal Costanza <p...@p-cos.net> writes:
>
>> JVM technology has come up with pretty impressive dynamic compilation
>> techniques and very advanced garbage collectors, to name just two
>> examples. It can be interesting to reuse such technology.
>
> Also, a higher level VM makes it easier for multiple languages to
> cooperate properly.
Who said I want to cooperate ? I'm all for language apartheid and
reimplementing everything from scratch.
> Does anyone really enjoy writing CFFI wrappers for
> C libraries?
No, better rewrite it in lisp.
Kaz Kylheku
> On Tue, 20 Jan 2009 23:12:59 +0000, Mark Wooding wrote:
>
>> Pascal Costanza <p...@p-cos.net> writes:
>>
>>> JVM technology has come up with pretty impressive dynamic compilation
>>> techniques and very advanced garbage collectors, to name just two
>>> examples. It can be interesting to reuse such technology.
>>
>> Also, a higher level VM makes it easier for multiple languages to
>> cooperate properly.
>
> Who said I want to cooperate ? I'm all for language apartheid and
> reimplementing everything from scratch.
If you're for language apartheid, you clearly belong in the Java project.
Marek Kubica
"jos...@corporate-world.lisp.de" <jos...@corporate-world.lisp.de> wrote:
> Not every process. But if you look at some companies, they are running
> each app in a different virtualized OS on blade servers.
Though it still does not make VMs like what Java and many other
languages use unneccessary, because that's just different things.
regards,
Marek
Rob Warnock
+---------------
| Kaz Kylheku wrote:
| > Why would I run some poor quality fake virtual machine when I can
| > virtualize an entire operating system, that has MMU based memory
| > management, its own TCP/IP stack, its own accurate process and
| > thread scheduler, etc.
|
| What has one got to do with the other?
| Want to run a separate OS for every process?
Heh. VM/CMS did *exactly* that! When you logged into a VM/CMS
session, you actually "booted" a fresh copy of the CMS operating
system within a new VM/370 virtual machine.
Sutherland's "Wheel of Reincarnation" strikes again! ;-}
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Pascal J. Bourguignon
The VM are still needed in the presence of virtualized OS because most
modern processors are not micro-codable anymore.
If the microcode could be changed for the user processes, instead of
implementing the instruction set in a virtual machine, we could
directly implement it in the processor "firmware", and then you would
have virtualized OS implementing directly the VM you need. You would
have native Java Machines, native Lisp Machines, native Prolog
Machines, etc running "directly" on the metal.
--
__Pascal Bourguignon__
Mark Evenson
[…]
> If anyone cares, I have some fancy functions for doing Java method and
> constructor overload resolution at run-time based on the dynamic
> argument types.)
As an ABCL maintainer, I would be interested in posting such a set a
functions to the armedbear mailing list for posterity/wider
distribution. Over time, all sorts of people seem to follow ABCL for a
bit, using the mailing list archives to "come-up-to-speed" on what
happened before. Currently, the Java constructor lookup is pretty
verbose, so I would welcome code to help bridge this more intelligently.
Personally, I find great utility in [Alan Ruttenberg's
invoke.lisp][1], but it actually uses the JScheme implementation under
the hood to find the constructor requiring addtional JARs on the JVM
classpath, so I would be interested in comparing it to a pure CL
implementation.
The armedbear mailing list is still the old armedbear-j-devel list
hosted on SourceForge. Unfortunately, the list accepts posts from
members only. If you want to send the code to me, I can make sure it
makes it to the list.
Eventually, we want to make the Java/Lisp interfaces as easy as
possible, but we are currently concentrating on getting ABCL to behave
more like a better CL before going for such extensions.
[1]: http://svn.mumble.net:8080/svn/lsw/trunk/jss/invoke.lisp
Sincerely,
Mark <eve...@panix.com>
--
"A screaming comes across the sky. It has happened before, but there is
nothing to compare to it now."
Matthias Buelow
> Heh. VM/CMS did *exactly* that! When you logged into a VM/CMS
> session, you actually "booted" a fresh copy of the CMS operating
> system within a new VM/370 virtual machine.
Yeah but I guess that's different from having n installations of Lignux
or Windows around, each of which boot up with unnecessary baggage (for a
1-service system) and each of which has to be operated and maintained
separately.
I mean, Ok, if you have a database system that you'd probably also run
on a separate machine, then that's ok to run in a virtualized machine on
a more powerful server instead. But that concept is orthogonal to the
Java-style VM.
Marco Antoniotti
> Matthias Buelow <m...@incubus.de> wrote:
> +---------------| Kaz Kylheku wrote:
>
> | > Why would I run some poor quality fake virtual machine when I can
> | > virtualize an entire operating system, that has MMU based memory
> | > management, its own TCP/IP stack, its own accurate process and
> | > thread scheduler, etc.
> |
> | What has one got to do with the other?
> | Want to run a separate OS for every process?
> +---------------
>
> Heh. VM/CMS did *exactly* that! When you logged into a VM/CMS
> session, you actually "booted" a fresh copy of the CMS operating
> system within a new VM/370 virtual machine.
>
> Sutherland's "Wheel of Reincarnation" strikes again! ;-}
>
> -Rob
>
> -----
Aren't the people who gave us VmWare (where I run Movitz :) )
coming from VM/CMS?
Cheers
--
Marco
http://www.european-lisp-symposium.org