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.
> 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 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.
> 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.
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. 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.
On Jan 20, 10:42 am, Pascal Costanza <p...@p-cos.net> wrote:
> 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)
Michael Weber wrote: > On Jan 20, 10:42 am, Pascal Costanza <p...@p-cos.net> wrote: >> 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)
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.
>> 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.
>>> 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.
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.
On Jan 20, 4:30 am, Slobodan Blazeski <slobodan.blaze...@gmail.com> 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.
>>> 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.
*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
Kaz Kylheku <kkylh...@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.
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. 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.
Robert Dodier <robert.dod...@gmail.com> writes: > 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.)
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?
How about portability to different architectures (the "write once, run everywhere" [yes, I know...])?
On 21 Jan., 17:48, 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?
> How about portability to different architectures (the "write once, run > everywhere" [yes, I know...])?
Not every process. But if you look at some companies, they are running each app in a different virtualized OS on blade servers.
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.
> Does anyone really enjoy writing CFFI wrappers for > C libraries?
>>> 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.
"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.
| > 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 <r...@rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
Marek Kubica <ma...@xivilization.net> writes: > On Wed, 21 Jan 2009 08:56:34 -0800 (PST) > "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.
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.
|
