Dylan to Java? 
Author Message
 Dylan to Java?

...

Quote:
> Being able to do so would clearly be an advantage, in terms of portability
> and speed of uptake of Dylan.  

   This would  perhaps be useful as an educational exercise.  Implementing
   a Dylan subset and targeting javabyte codes (with some library infrastructure)
   would be interesting.  Or maybe a Dylan "interaction" interpreter where you
   don't need to do a complicated install.   In essence, a good "introduction"
   mechanism.  You can kick the tires on "hello world" type programs and see
   what it is all about.

   Although, it would be portable I'm not sure it would speed the adoption
   of Dylan.  There would be significant performance problems.  
   Lisp still labors under the "Lisp is slow" legend.  In the big picture
   and long term, I'm not sure this wouldn't create the same sort of "mislabel"
   on Dylan.  If you make an easily downloadable "slow" implementation
   folks probably will slap a label on the language as a whole.

   [ There is a costfree version of Dylan for Windows and Linux/Unix. When
     MacOS X enters it should not take long for the Linux/Unix flavor to show
     up. That set of platforms covers alot of ground.  So it is almost
     ubiquitously available.   That's primarily what a bytecode version would
     buy, IMHO. ]

Quote:
> I know this was looked at back in the days when Thomas and Marlais were
> state of the art implementations, and if I recall the answer was basically

   You also need to throw in the totally different exception model (e.g., restarts)
   that Dylan has versus the JVM/Java.  You could "subset" the language, but then it
   wouldn't be Dylan(tm) anymore. :-)

   You also need a "homegrown" object model since Java isn't multiple inheritance.

   [ IHMO i'd label d2c's use of C as a "portable assembly"  rather than
     compiling code to a "C machine".  Java bytecode isn't really optimize
     for being a "portable assembly" if you deviate from the "java way".  ]

Quote:
> But we now have compilers that can eliminate most of the generic function

   What is "most"?  The fact that just about everything is a generic function
   means that if you elminate 80%, the remaining 20% may still be larger than
   the dynamic dispatch than would be present in a C++/Java program (that
   are optimized to a similar extent).  

   For programs extremely dominated by sealed classes/generics/domains prehaps
   this would result in a very small number.  But how "typical" are those types
   of programs?

   Neither one of the questions have alot of empirical evidence behind them one
   way or the other.

Quote:
> Is it now relatively easy to retarget the back end of, say, d2c to produce
> Java instead of C?  

   Perhaps after it is cleaned up. :-)   I don't recall "relatively easy"
   occuring very often in discussions of the optimizer.

   [ An additional "wouldn't it be nice" alternative would be to target the GCC
     back end (i.e. create an egcs/gcc "front end"), which in turn is targeted
     to many native formats. You'd need a very easy way to do c bindings and
     linkage for this.]

Quote:
> might be possible to have little speed disadvantage over Java...  

    I doubt that. Java will always have an "home court" advantage when it
    comes to the JVM and bytecodes.  It is like playing the Celtics on the
    parquet floor. They know where all the "dead spots" are.  Add to that the
    "Dylan Virtual Machine" you have to layer on top and the overhead should
    be quite noticable.

    I also don't think Java, the language, makes a particularly good "portable
    assembly" language.  C has problems fullfilling this role and Java
    doesn't improve on that.

---

Lyman



Thu, 29 Nov 2001 03:00:00 GMT  
 Dylan to Java?
Has anyone looked at compiling Dylan to Java and/or directly to Java byte
codes recently?

Being able to do so would clearly be an advantage, in terms of portability
and speed of uptake of Dylan.  Not to mention not having to write in Java
any more :-)

I know this was looked at back in the days when Thomas and Marlais were
state of the art implementations, and if I recall the answer was basically
that since the JVM doens't support multimethods whatever you did for
generic function dispatch was going to be ugly and slow.  Quite possibly
you'd also be forced to use Integer etc classes rather than int all the
time, which would be slow as well.

But we now have compilers that can eliminate most of the generic function
dispatches, and that can happily use C "int" variables and box and unbox
as necessary, and generate asembler or C that is pretty to close to native
C programs in speed.

Is it now relatively easy to retarget the back end of, say, d2c to produce
Java instead of C?  The result would of course be slower than C, but it
might be possible to have little speed disadvantage over Java...  When you
have to do full generic function dispatch it would still be ugly and slow,
but perhaps that is not too frequent now?

Is this worth revisiting?

-- Bruce



Fri, 30 Nov 2001 03:00:00 GMT  
 Dylan to Java?

Quote:
> > But we now have compilers that can eliminate most of the generic function
>    What is "most"?  The fact that just about everything is a generic function
>    means that if you elminate 80%, the remaining 20% may still be larger than
>    the dynamic dispatch than would be present in a C++/Java program (that
>    are optimized to a similar extent).  

It wouldn't matter if only 10% of the cases were eliminated, if those
are the 10% of code which make up for 90% of the program runtime.

Quote:
> > Is it now relatively easy to retarget the back end of, say, d2c to produce
> > Java instead of C?  

>    Perhaps after it is cleaned up. :-)   I don't recall "relatively easy"
>    occuring very often in discussions of the optimizer.

The d2c optimizer is a mess, but the C backend is very
clean. Producing Java source instead of C shoud be doable. I just
don't see the point at the moment, there are more important problems
to solve.

Quote:
>    [ An additional "wouldn't it be nice" alternative would be to target the GCC
>      back end (i.e. create an egcs/gcc "front end"), which in turn is targeted
>      to many native formats. You'd need a very easy way to do c bindings and
>      linkage for this.]

Yes, that would be nice. Unfortunately the gcc backend interface is a
set of C functions, and not some text representation.

Andreas

--
Reality is two's complement. See:
ftp://ftp.netcom.com/pub/hb/hbaker/hakmem/hacks.html#item154



Fri, 30 Nov 2001 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

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

2. Dylan to Java/JVM compiler?

3. Advantages of Dylan over Java (second try)

4. Advantages of Dylan over Java

5. Advantages of Dylan over Java?

6. Dylan over Java P-machine?

7. Dylan to Java/JVM compiler?

8. java and dylan [was: JAVA IS OBSELETE AND WILL DIE!!!!!!!!]

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

10. Calling Java from Dylan

11. (HD) Java Dylan interoperability

12. Dylan Java Source Code Comparison

 

 
Powered by phpBB® Forum Software