On 9 mar, 17:26, camponoblanco <·············@gmail.com> wrote:
> A proof of Lisp strength would be to implement a java to lisp
> translator.
>
> How many hours do you think this would take?
If Scheme is OK, there PLT distributes a very interesting Java
interpreter.
camponoblanco wrote:
> A proof of Lisp strength would be to implement a java to lisp
> translator.
>
> How many hours do you think this would take?
A basic version: 16 hours. (It was one of my first projects in Common
Lisp...)
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Mar 9, 10:04 pm, Pascal Costanza <····@p-cos.net> wrote:
> camponoblanco wrote:
> > A proof of Lisp strength would be to implement a java to lisp
> > translator.
>
> > How many hours do you think this would take?
>
> A basic version: 16 hours. (It was one of my first projects in Common
> Lisp...)
There's also a less basic version, jnil (http://common-lisp.net/
project/jnil/) - users & developers keen to show off their or Lisp's
strengths are both welcome...
On Mar 9, 3:23 pm, TomSW <·············@gmail.com> wrote:
>
> There's also a less basic version, jnil (http://common-lisp.net/
> project/jnil/) - users & developers keen to show off their or Lisp's
> strengths are both welcome...
Ah, a source-to-source translator. That could be useful.
David Lichteblau's Cloak project also comes to mind. He was
translating Java bytecodes to CL. He was shooting for absolute
compatibility. As an example of what that means, IIRC, Eclipse, which
he wanted to be able to run, does weird things like triggering an
exception so it can look at the stack backtrace captured in the
exception object; this lets some routine that's way down in the call
graph do different things depending on what call path it was reached
by. This is a really gross way to get the effect of a dynamic
binding. (I may be misremembering this; it's been a while since he
explained it to me.) So for Cloak, he had to make sure the backtrace
captured in exception objects was sufficiently similar to the one the
JVM would supply. And this is just one example of what's needed for
complete compatibility.
I think if I were to undertake a similar project, I would be willing
to sacrifice some compatibility in favor of performance on the
particular Java code I'm interested in running (computational
libraries, mostly, which are unlikely to do weird shit like
programmatically analyzing exception backtraces). At one point I
thought I might help out with Cloak, but it hasn't turned out to be a
priority for me.
Anyway, I'll have a look at Jnil.
-- Scott
From: Javier
Subject: Re: How difficult would be to implement java to lisp?
Date:
Message-ID: <gp4t9r$srs$1@aioe.org>
Pascal Costanza escribi�:
> camponoblanco wrote:
>> A proof of Lisp strength would be to implement a java to lisp
>> translator.
>>
>> How many hours do you think this would take?
>
> A basic version: 16 hours. (It was one of my first projects in Common
> Lisp...)
Using this:
http://catalog.compilertools.net/java.html
It can take also some hours to implemente a basic interpreter of Lisp in
Java.
Javier wrote:
> Pascal Costanza escribi�:
>> camponoblanco wrote:
>>> A proof of Lisp strength would be to implement a java to lisp
>>> translator.
>>>
>>> How many hours do you think this would take?
>> A basic version: 16 hours. (It was one of my first projects in Common
>> Lisp...)
>
> Using this:
>
> http://catalog.compilertools.net/java.html
>
> It can take also some hours to implemente a basic interpreter of Lisp in
> Java.
My project was a portable just-in-time compiler. :-P
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Javier
Subject: Re: How difficult would be to implement java to lisp?
Date:
Message-ID: <gp4stt$snj$1@aioe.org>
camponoblanco escribi�:
> A proof of Lisp strength would be to implement a java to lisp
> translator.
>
> How many hours do you think this would take?
>
>
Take in consideration that there are already various implementations of
several Lisp dialects (including a couple of Common Lisps) already
implemented in Java. Have a look:
http://www.is-research.de/info/vmlanguages/lisp/
So you have no advantage in this, unless you can demonstrate that a full
implementation of Java in CL takes less time than a full implementation
of CL in Java.
From: J Kenneth King
Subject: Re: How difficult would be to implement java to lisp?
Date:
Message-ID: <871vt5sai3.fsf@agentultra.com>
Javier <·······@gmail.com> writes:
> camponoblanco escribió:
>> A proof of Lisp strength would be to implement a java to lisp
>> translator.
>>
>> How many hours do you think this would take?
>>
>>
>
> Take in consideration that there are already various implementations of
> several Lisp dialects (including a couple of Common Lisps) already
> implemented in Java. Have a look:
>
>
> http://www.is-research.de/info/vmlanguages/lisp/
>
>
> So you have no advantage in this, unless you can demonstrate that a full
> implementation of Java in CL takes less time than a full implementation
> of CL in Java.
I've seen a prototype implementation of a Lisp in Perl.
The presenter posed the question: Lispy-perl or Perlish-lisp?
Either way, what I got from it was that the implementation is likely to
have an interconnect or artifacts of the host present.
This is what I see in Clojure; it looks like a Lispy-java. Largely
because of its Java interconnect and also because of some of the design
sacrifices it had to leave behind (conditions/restarts, TCO, images) due
to Java's implementation and execution model.
I also thought that the sequence abstraction would be useful, but as I
learned quickly both from c.l.l and on my own; it really isn't so useful
as to force it to be a part of the language core.
So Clojure is Java-ish and Clojure-ish. It's a neat niche tool, but not
a full replacement for CL (I think this is the second time I've
mentioned this, sorry).