Dylan to Java/JVM compiler? 
Author Message
 Dylan to Java/JVM compiler?

Is any work being done on compiling Dylan source to Java class-files (or
java source, for that matter)? This would enable Dylan programs to run
on the plethora of JVM's in existance.

Roland



Mon, 20 Oct 2003 20:36:04 GMT  
 Dylan to Java/JVM compiler?

Quote:

> Is any work being done on compiling Dylan source to Java class-files (or
> java source, for that matter)? This would enable Dylan programs to run
> on the plethora of JVM's in existance.

Nobody is working on that, as far as I know. I assume that it simply
wouldn't run fast enough, since most of the Dylan language primitives
would need to be emulated.

Andreas

--
"Der Pirat des Wissens ist ein guter Pirat."

  -- Michel Serres,
     http://www.heise.de/tp/deutsch/inhalt/co/3602/1.html



Mon, 20 Oct 2003 21:13:13 GMT  
 Dylan to Java/JVM compiler?

Quote:


>> Is any work being done on compiling Dylan source to Java class-files
>> (or
>> java source, for that matter)? This would enable Dylan programs to run
>> on the plethora of JVM's in existance.

> Nobody is working on that, as far as I know. I assume that it simply
> wouldn't run fast enough, since most of the Dylan language primitives
> would need to be emulated.

I'm sure I heard that Harlequin were working on something, and there
were very old documents floating around the CMU AI repository regarding
Dylan and Java. But the dispatch model is so different that Dylan code
compiled to Java could be very inefficient (although I suppose it would
"only" be a tree of switch statements for each GF call).

- Rob.



Mon, 20 Oct 2003 21:58:35 GMT  
 Dylan to Java/JVM compiler?

Quote:

> But the dispatch model is so different that Dylan code
> compiled to Java could be very inefficient (although I suppose it would
> "only" be a tree of switch statements for each GF call).

The whole idea in Dylan is to minimize the number of fully-general GF
dispatches that need to be made through compile-time analysis.


Tue, 21 Oct 2003 04:32:24 GMT  
 Dylan to Java/JVM compiler?

Quote:


> > Is any work being done on compiling Dylan source to Java class-files (or
> > java source, for that matter)? This would enable Dylan programs to run
> > on the plethora of JVM's in existance.

> Nobody is working on that, as far as I know. I assume that it simply
> wouldn't run fast enough, since most of the Dylan language primitives
> would need to be emulated.

Since Dylan is quite close to Scheme at some levels, start with Kawa
[1] as a base may be a start. They seem to get quite respectable
speed.

http://www.gnu.org/software/kawa/

Chris.
--
http://www.double.co.nz/dylan  



Tue, 21 Oct 2003 05:02:55 GMT  
 Dylan to Java/JVM compiler?

Quote:
> The whole idea in Dylan is to minimize the number of fully-general GF
> dispatches that need to be made through compile-time analysis.

As Jeffrey Siegal suggests, the Holy Grail of Dylan was to create a
language, runtime, and compiler that incorporated the best aspects of Common
Lisp/Scheme (dynamism - interacting with and/or modifying a running
application, generic functions, closures, macros) and go beyond them (OO
from the ground up - e.g., writing methods that specialize on individual
instances of built-in classes - not possible in CLOS, macros that are
hygenic - unlike Common Lisp macros), all while generating compiled code
that is as fast as the fastest statically compiled languages like C, or
fortran.

If one creates a Dylan that targets a JVM, one just ends up with yet another
lisp-like language, but without the execution speed of even a good Common
Lisp compiler.

On a different tack, there's already a Dylan that compiles to byte code -
Mindy (Mindy Is Not Dylan Yet). Possibly one could look at that and see if
it could be retargeted to the JVM.

Raf

Raffael Cavallaro, Ph.D.



Tue, 21 Oct 2003 10:52:13 GMT  
 Dylan to Java/JVM compiler?

Quote:

> ... But the dispatch model is so different that Dylan code
> compiled to Java could be very inefficient (although I suppose it would
> "only" be a tree of switch statements for each GF call).

I imagine a GF call would map to a virtual method invocation, or a series of
such, in java? I can't really imagine implementing it any more efficiently
in any dylan implementation (but I know nothing!)

Roland



Tue, 21 Oct 2003 16:43:22 GMT  
 Dylan to Java/JVM compiler?

Quote:


> > The whole idea in Dylan is to minimize the number of fully-general GF
> > dispatches that need to be made through compile-time analysis.

> As Jeffrey Siegal suggests, the Holy Grail of Dylan was to create a
> language, runtime, and compiler that incorporated the best aspects of Common
> Lisp/Scheme (dynamism - interacting with and/or modifying a running
> application, generic functions, closures, macros) and go beyond them (OO
> from the ground up - e.g., writing methods that specialize on individual
> instances of built-in classes - not possible in CLOS, macros that are
> hygenic - unlike Common Lisp macros), all while generating compiled code
> that is as fast as the fastest statically compiled languages like C, or
> Fortran.

CL is OO from the ground up in any reasonable definition of the
term. And you might want to study CLOS a bit more before pronouncing
things impossible ;-)

CL-USER 1 > (defgeneric hello ((object t))
              (:method ((object t))
                 (format *debug-io* "Method not implemented~%")))
#<STANDARD-GENERIC-FUNCTION HELLO 2050B24C>

CL-USER 2 > (hello 'foo)
Method not implemented
NIL

CL-USER 3 > (hello 'world)
Method not implemented
NIL

CL-USER 4 > (defmethod hello ((object (eql 'world)))
              (format *debug-io* "Hello world!"))
#<STANDARD-METHOD HELLO NIL ((EQL WORLD)) 21220954>

CL-USER 5 > (hello 'foo)
Method not implemented
NIL

CL-USER 6 > (hello 'world)
Hello world!
NIL

Quote:
> If one creates a Dylan that targets a JVM, one just ends up with yet another
> lisp-like language, but without the execution speed of even a good Common
> Lisp compiler.

Is there at this moment a Dylan compiler that beats a good CL compiler
on equivalent code? Theoretically, the Dylan compiler can potentially
do better by the sealing constructs, but that's about the only
difference I see between CL and Dylan w.r.t. possible optimisation.

--

Glaer ok reifr skyli gumna hverr, unz sinn ber bana.



Wed, 22 Oct 2003 01:06:25 GMT  
 Dylan to Java/JVM compiler?

Quote:

> Is there at this moment a Dylan compiler that beats a good CL compiler
> on equivalent code?

I don't know -- are there any non-trivial programs available for both?

I would be surprised if Fun-O wasn't at least as good as any Windows CL
compiler.  Gwydion is a bit more patchy -- on fairly static code it can
do as well as C for many things, but our GF dispatch code isn't
currently all that fast.  Mind you, it may well match things like CMUCL.

Quote:
> Theoretically, the Dylan compiler can potentially
> do better by the sealing constructs, but that's about the only
> difference I see between CL and Dylan w.r.t. possible optimisation.

I agree, if CL lets you declare integers to not be arbitrary precision.  
Oh, and I don't think CL has a good alternative for Dylan's "limited
collections" either.

I'm happy to be corrected.

-- Bruce



Wed, 22 Oct 2003 06:16:47 GMT  
 Dylan to Java/JVM compiler?

Quote:
> CL is OO from the ground up in any reasonable definition of the
> term. And you might want to study CLOS a bit more before pronouncing
> things impossible ;-)

Sorry, I clearly misspoke when I wrote that specializing on instances of
built-in classes was impossible in CLOS. I was confusing this with the
inability to subclass built-in classes. Anyway, here's the full HyperSpec
passage on the limitaions of CLOS built-in classes:

"A built-in class is a class whose instances have restricted capabilities or
special representations. Attempting to use defclass to define subclasses of
a built-in class signals an error of type error. Calling make-instance to
create an instance of a built-in class signals an error of type error.
Calling slot-value on an instance of a built-in class signals an error of
type error. Redefining a built-in class or using change-class to change the
class of an instance to or from a built-in class signals an error of type
error. However, built-in classes can be used as parameter specializers in
methods. "

So CLOS built-in classes are a bit like primitive types, in that, there are
things one can do with other classes and objects that one may not do with
CLOS built-in classes or instances thereof. In this regard, CLOS is not OO
from the ground up in the way Smalltalk,for example, is. Of course Smalltak
lacks multiple inheritance and multiple dispatch, so...

Quote:
> Is there at this moment a Dylan compiler that beats a good CL compiler
> on equivalent code? Theoretically, the Dylan compiler can potentially
> do better by the sealing constructs, but that's about the only
> difference I see between CL and Dylan w.r.t. possible optimisation.

You may recall that I referred to the "Holy Grail of Dylan..." I didn't
claim that it had been achieved. Personally I prefer Common Lisp, because I
think that Dylan, as implemented to date, has more the feel of a statically
compiled language, despite its name (DYnamic LANguage). I even prefer
Smalltalk to Dylan because it is implemented more dynamically.

Thanks for pointing out my error in any event.

Regards,

Raf

--

Raffael Cavallaro, Ph.D.



Wed, 22 Oct 2003 07:07:01 GMT  
 Dylan to Java/JVM compiler?

Quote:



> > Is there at this moment a Dylan compiler that beats a good CL compiler
> > on equivalent code?

> I don't know -- are there any non-trivial programs available for both?

I assume the Gabriel benchmarks have been ported.

Quote:
> I would be surprised if Fun-O wasn't at least as good as any Windows CL
> compiler.  Gwydion is a bit more patchy -- on fairly static code it can
> do as well as C for many things, but our GF dispatch code isn't
> currently all that fast.  Mind you, it may well match things like CMUCL.

You might get a good run for your money by CMUCL. CMUCL does a great
job in type inference. It also has a non standard extension
(block-compile) that lets you declare that functions won't be
redefined or called from without the block, which gives you some of
the benefits of sealing. Only CMUCL's PCL based CLOS implementation
isn't very fast.

Quote:
> > Theoretically, the Dylan compiler can potentially
> > do better by the sealing constructs, but that's about the only
> > difference I see between CL and Dylan w.r.t. possible optimisation.

> I agree, if CL lets you declare integers to not be arbitrary precision.  

(declare (type fixnum x))
or even
(declare (type (integer 1 10) y))

Quote:
> Oh, and I don't think CL has a good alternative for Dylan's "limited
> collections" either.

(make-array '(10 10) :element-type '(unsigned-byte 2))

(declare (type (vector 'simple-float 128) v))

With some tricks you can even do it for lists, where it won't buy you
much.

--

Glaer ok reifr skyli gumna hverr, unz sinn ber bana.



Wed, 22 Oct 2003 21:02:24 GMT  
 Dylan to Java/JVM compiler?

Quote:

> So CLOS built-in classes are a bit like primitive types, in that, there are
> things one can do with other classes and objects that one may not do with
> CLOS built-in classes or instances thereof. In this regard, CLOS is not OO
> from the ground up in the way Smalltalk,for example, is. Of course Smalltak
> lacks multiple inheritance and multiple dispatch, so...

I don't know enough about Smalltalk to be sure about this, but is it
really supported to derive from the built in integers and redefine
addition? In general, a lot of languages I would consider OO from the
ground up like Eiffel have restrictions on some of the basic
classes. It's the only way to be able to compile some basic stuff
efficiently into machine primitives.

I see in the drm at gwydiondylan.org that <integer> is a sealed class,
so Dylan is as OO as CLOS in this respect.

Quote:
> > Is there at this moment a Dylan compiler that beats a good CL compiler
> > on equivalent code? Theoretically, the Dylan compiler can potentially
> > do better by the sealing constructs, but that's about the only
> > difference I see between CL and Dylan w.r.t. possible optimisation.

> You may recall that I referred to the "Holy Grail of Dylan..." I didn't
> claim that it had been achieved.

A pity. I look at Dylan as an experiment in the efficiency of sealing
constructs but from a negative result no conclusions can be drawn,
since there has been invested a lot more effort in CL compilers than
in Dylan compilers. It would have been nice if Dylan got a factor 10
improvement out of it.

Quote:
> Personally I prefer Common Lisp, because I think that Dylan, as
> implemented to date, has more the feel of a statically compiled
> language, despite its name (DYnamic LANguage).

It is dynamic in comparison to mainstream languages like C++ and
Java. One of the design goals from the beginning was to be less
dynamic than CL to avoid including a signifant part of the compiler in
applications to support things like EVAL and COMPILE.

I wonder why they kept dispatching on instances. It's a feature I'd
remove from CLOS since it doesn't add much to the expressiveness of
the language and interferes with optimizing GF dispatch.

--

Glaer ok reifr skyli gumna hverr, unz sinn ber bana.



Wed, 22 Oct 2003 21:20:27 GMT  
 Dylan to Java/JVM compiler?

Quote:

>I don't know enough about Smalltalk to be sure about this, but is it
>really supported to derive from the built in integers and redefine
>addition? In general, a lot of languages I would consider OO from the
>ground up like Eiffel have restrictions on some of the basic
>classes. It's the only way to be able to compile some basic stuff
>efficiently into machine primitives.

It's not the only way. The other way is to provide the semantics of
objects throughout, but optimize most cases to efficient machine primitives.

Quote:
>I see in the drm at gwydiondylan.org that <integer> is a sealed class,
>so Dylan is as OO as CLOS in this respect.

Yes, but <integer> inherits from <rational> inherits from <real> inherits
from <complex-number> inherits from <number>, which is *open*. So all the
"specific" classes are sealed for efficient compilation, but the root of
that numeric hierarchy is open, allowing for subclassing of <number>. Now
if you truly need to subclass <integer>, this is not exactly what you
want. But if you want to add a new numeric type and add methods that
specialize on it, you can do so.

This seems to be a common idea in Dylan: seal many classes for
efficiency, but leave something up the hierarchy open for unanticipated
needs for expansion.

Scott Ribe

http://www.killerbytes.com/
(303) 665-7007 voice



Thu, 23 Oct 2003 08:05:57 GMT  
 Dylan to Java/JVM compiler?

Quote:

> Yes, but <integer> inherits from <rational> inherits from <real> inherits
> from <complex-number> inherits from <number>, which is *open*. So all the
> "specific" classes are sealed for efficient compilation, but the root of
> that numeric hierarchy is open, allowing for subclassing of <number>. Now
> if you truly need to subclass <integer>, this is not exactly what you
> want. But if you want to add a new numeric type and add methods that
> specialize on it, you can do so.

So the usual operations like + , * etc. are generic
functions. Nice. For historical reasons they aren't in CL. Off course,
in CL they're also variadic and floating point contagion is already
complex enough. Adding user defined numeric types into it probably
wouldn't be worth it.

--

Glaer ok reifr skyli gumna hverr, unz sinn ber bana.



Thu, 23 Oct 2003 23:27:36 GMT  
 Dylan to Java/JVM compiler?


Quote:
> I wonder why they kept dispatching on instances. It's a feature I'd
> remove from CLOS since it doesn't add much to the expressiveness of
> the language and interferes with optimizing GF dispatch.

In Dylan it gets used for separating public abstract interface classes and
private concrete implementation classes:

define method make ( class == <interface>, #key, #rest initargs )
  apply( make, <implementation>, initargs);
end method;

__Jason



Sat, 25 Oct 2003 17:37:05 GMT  
 
 [ 26 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Dylan to Java/JVM compiler?

2. Redefining CAR/CDR/other standard symbols (was Re: [Q] Dylan to Java/JVM compiler?)

3. Dylan and Java [was: Harlequin Dylan - Update]

4. Port Oberon to Java/JVM

5. SmallEiffel, jvm, and java methods with no result?

6. wanted: Ada binding for Java Swing to target JVM

7. patch to Modules/posixmodule.c for Java JVM compatibility

8. Eiffel-JVM Compiler?

9. Haskell to JVM Compiler

10. Open source Component Pascal compiler for JVM and .NET

11. Eiffel Compiler with JVM bytecode generation

12. Calling Java from Dylan

 

 
Powered by phpBB® Forum Software