Dylan -> Java?? 
Author Message
 Dylan -> Java??

I've not had much time to play around with my copy of Apple Dylan,
because I've had to spend most of my learning time with Java (and
it's legacy syntax - like the integer based switch statement...)

I'd much rather be using Dylan - then it occured to me that in
theory it wouldn't be that hard to have Dylan use Java classes
and produce Java  byte code applications and applets.

Is anybody working along these lines? It -would- be a good way to
bring Dylan into the mainstream imho.



Wed, 14 Apr 1999 03:00:00 GMT  
 Dylan -> Java??

Quote:
> One of the problems with that idea is that the Java byte-codes are not
> language-neutral; their specific to Java. There's already been work done
> to compile Ada95 and Scheme to Java byte-codes, so it's possible to host
> other languages on the Java virtual machine.

> I don't know anything about Ada95's object system, but I suspect it
> would be fairly hard to target Dylan at the java machine because of
> multiple inheritance and mulitple dispatch.

I've heard comments that those last two items are a problem, but there are
proposals to add support for them to the Java VM. See

  <http://www.ai.mit.edu/~shivers/javaScheme.html>

for example. Maybe interested parties should pester Sun/JavaSoft to support
"other" languages?

...........................................................................

Dylan Hacker                                     http://www.best.com/~page/
Harlequin Incorporated                            http://www.harlequin.com/

    Learn more about Dylan at: http://www.cambridge.apple.com/
                               http://legend.gwydion.cs.cmu.edu/dylan/
...........................................................................



Fri, 16 Apr 1999 03:00:00 GMT  
 Dylan -> Java??

One of the problems with that idea is that the Java byte-codes are not
language-neutral; their specific to Java. There's already been work done
to compile Ada95 and Scheme to Java byte-codes, so it's possible to host
other languages on the Java virtual machine.

I don't know anything about Ada95's object system, but I suspect it
would be fairly hard to target Dylan at the java machine because of
multiple inheritance and mulitple dispatch.

Quote:
>----------

>Sent:       Saturday, October 26, 1996 10:11 AM

>Subject:    Dylan -> Java??

>I've not had much time to play around with my copy of Apple Dylan,
>because I've had to spend most of my learning time with Java (and
>it's legacy syntax - like the integer based switch statement...)

>I'd much rather be using Dylan - then it occured to me that in
>theory it wouldn't be that hard to have Dylan use Java classes
>and produce Java  byte code applications and applets.

>Is anybody working along these lines? It -would- be a good way to
>bring Dylan into the mainstream imho.



Fri, 16 Apr 1999 03:00:00 GMT  
 Dylan -> Java??

....

Quote:
>> would be fairly hard to target Dylan at the java machine because of
>> multiple inheritance and mulitple dispatch.

>I've heard comments that those last two items are a problem, but there are
>proposals to add support for them to the Java VM. See

>  < http://www.*-*-*.com/ ~shivers/javaScheme.html>

>for example. Maybe interested parties should pester Sun/JavaSoft to support
>"other" languages?

 I'm not sure what progress is being made on this, but I was under the
 impression that Guy Steele was looking at this a bit. There are some
 folks internal to Sun who think that adding a few hooks to make life easier
 for languages (like Scheme, Dylan) that do more than what java does would be
 a good thing.....
 However, there are also folks who want to keep the VM as simple as possible.
 In talking with a very small number of folks ( so it may be an inaccurate
 inference), that the latter group was bigger and more vocal.

 In side hallway discussion with Steele and some others at a conference last
 year I got the impression that some small set of features were under
 consideration to be put into the next revision VM to fix identified problems
 ( i.e. lack of VM to do introspection. ) and that some support for closures
  (perhaps or other features.. ) could be added at that point.  But after VM
 "2.0" that things would be pretty much calcified due to the pressure that so
 many people would be using it....

 Three points...

 Point 1.
 Given that folks like Microsoft et. al. all have their own version of the
 VM now, if Sun puts some feature that they all will "{*filter*}on" into the
 VM then Java will loose some of the "hype" javasoft has so finely crafted
 for the last year or so.  Or possibly others would "zig" where Sun "zag".
 If the feature won't improve the perfomance of Java code then there are lots
 of folks who are going to cry "foul".  Or you put the VM on a slippery slope
 where various language bigots want their favorite feature in
 ( can we say C++ boys and girls?? ).

Point 2.
As far a proliferating the VM everywhere. More work is being done outside
of Sun at this point then inside. The calcification point refered to above
may be been reached already... software wise.

 Point 3...
 Tomorrow Sun is going to introduce the "java machine" with the VM
 implemented in silicon. If VM "2.0" obsoleted your CPU you're
 going to be pissed off.  A sort of physical manifestation of the
 "calcification" they were anticpating last year.

 So augmenting the VM is looking very dim, but hasn't totally been
 ruled out.  If anyone from JavaSoft would like comment... feel free. :-)

 The VM is relatively Turing complete though. So layering Dylan code on
 top of the VM isn't impossible. It isn't going to be very efficient, but
 you can you can implement closures with objects. And (I think) you can
 implement multimethod dispatch using a series of single reciever messages.  
 And with enough gyrations you can turn a mutliple inheir. network into a
 single inheir. network...  It could potentially get WAY ugly though.
 [ Essentially you could build a Dylan VM on top the VM.  I don't think
   anyone would be "happy" with it though. ]

 [ I won't even touch the fact that JavaFoft folks were looking at
   not only the fact that the bytecodes were efficient, but how well
   they compressed.... the latter might the counter productive with
   "extensions" or extensible bytecodes. This all spurred on by improving the
   download times of bytecodes over the internet. ]

 P.S. In reference to the proposals in the above paper. Those extension
      seem to be hard to implement in silicon.... O.K. in RISC (no
      microcode ) like silicon. If you did implement it in silicon it seems
      like it would look alot like the old LISP machine CPU's (downloadable
      microcode... special "stack" registers ) ...and if
      Sun did that all the other CPU vendors would call them bad names.... :-)
      "They're implementing a Lisp machine... we all know that was a dismal
       failure.." That sort of stuff.  If you're on the "hype train" you
       don't want folks saying this about you.

   Besides in these heavily superscalar CPU's taking exceptions is a
   non trival performance reducer. Remember the VM is a description of a
   machine. It isn't an implementation. The implementation of the VM may
   be in software, in hardware, or an amalgamation of both ( a JIT ).

   Two, if your going to have digitally signed stuff you might as well
   go with the "generic risc machine code and recompile for target
   machine when you get there" approach that Colusa had.  Unfortunately,
   they have been assimilated by the Borg.... eerrrr I mean acquired by
   Microsoft. There you would have a general purpose risc architecture
   to target and all this goes away.
   [ "Microsoft" was suppose to put the Colusa technology on the Web at some
     point.... However, I haven't seen it yet.  However, if ActiveX is
     every suppose to be truely multiplatform I would imagine that it
     will surface eventually.  ]

--

Lyman S. Taylor              "We are Microsoft.  

                                  resistance is futile.  
                                        Prepare to be assimilated."
                                .sig seen while netsurfing the Internet.



Fri, 16 Apr 1999 03:00:00 GMT  
 Dylan -> Java??


|>
|> One of the problems with that idea is that the Java byte-codes are not
|> language-neutral; their specific to Java. There's already been work done
|> to compile Ada95 and Scheme to Java byte-codes, so it's possible to host
|> other languages on the Java virtual machine.
|>
|> I don't know anything about Ada95's object system, but I suspect it
|> would be fairly hard to target Dylan at the java machine because of
|> multiple inheritance and mulitple dispatch.
|>

Agreed. Especially, Java's dispatch tables are hard-coded in the Java byte
code. This is not a problem for Ada95, which also supports single inheritance.
When compiling a Dylan program to Java bytecode, the run-time dispatch code
should be part of the generated Java bytecode, a serious performance penalty
wrt Java and Ada 95.

An optimizing compiler could however detect the generic functions that do
not use multiple dispatch and multiple inheritance, and compile them to
generate Java-like dispatch tables. The performance penalty would be only
observed for more complex generic functions. Using type information, for
a given generic function the compiler may even use (fast) Java-like dispatch
on some invocations and (slow) byte-coded dispatch for others. Assume the
following classes and methods:

  A   B         m(A)
   \ /          m(B)
    C           m(C)
   / \          m(D)
  D   E         m(E)

Assume myA, myB and myC have respective types A, B and C: for invocations
m(myA) and m(myB), byte-coded dispatch should be used because the run-time
argument may be an instance of C and C multiply inherits from A and B.
However for m(myC) Java-like dispatch can be used because no multiple
inheritance appears below C.

I hope you get the idea. Now, who volunteers to implement that ? :-)

Eric

--

Lucent Technologies - Bell Laboratories
Room 2C-234, 600 Mountain Avenue, P.O. Box 636      Phone: (908) 582-7153
Murray Hill, NJ 07974-0636, USA                     Fax  : (908) 582-5809



Sun, 18 Apr 1999 03:00:00 GMT  
 Dylan -> Java??

Quote:

>An optimizing compiler could however detect the generic functions that do
>not use multiple dispatch and multiple inheritance, and compile them to
>generate Java-like dispatch tables. The performance penalty would be only
>observed for more complex generic functions. Using type information, for
>a given generic function the compiler may even use (fast) Java-like dispatch
>on some invocations and (slow) byte-coded dispatch for others. Assume the
>following classes and methods:

>  A   B         m(A)
>   \ /          m(B)
>    C           m(C)
>   / \              m(D)
>  D   E             m(E)

>Assume myA, myB and myC have respective types A, B and C: for invocations
>m(myA) and m(myB), byte-coded dispatch should be used because the run-time
>argument may be an instance of C and C multiply inherits from A and B.
>However for m(myC) Java-like dispatch can be used because no multiple
>inheritance appears below C.

It's a good idea, and it will work under many circumstances.  However,
it will also fail more often then you might think: Unless the generic
function in question is both defined in the same library as the class
and is sealed, Java dispatch can't be used.  (This assumes we're doing
per-library compilation.  If you're doing whole-program compilation,
you can do just about anything.)

In Dylan, there are a lot of cases where some optimization appears
doable, even obvious, but actually isn't.  Unsealed generic functions
have more degrees of freedom than we usually think.  Some common
screws are: a method could be added or removed at runtime, a single
dispatch generic could be turned into a double-dispatch generic
because someone added a new method, and the method that is "obviously"
the right method may be shadowed by another method specialized on a
singleton.  Usually these things don't happen, but without either
sealing or whole-program optimization, there's no way for the compiler
to be sure.

Quote:
>I hope you get the idea. Now, who volunteers to implement that ? :-)

Today's a little busy, but maybe tomorrow.  ;)
--

-Nick Kramer



Mon, 19 Apr 1999 03:00:00 GMT  
 Dylan -> Java??



Quote:
> Point 3...
> Tomorrow Sun is going to introduce the "java machine" with the VM
> implemented in silicon. If VM "2.0" obsoleted your CPU you're
> going to be pissed off.  A sort of physical manifestation of the
> "calcification" they were anticpating last year.

According to the JavaStation spec I read, it boots from the network or
flash memory.  There obviously has to be some minimal stuff hard-wired in
ROM, but the OS on a network server can be updated with a new VM, and this
can be downloaded into flash memory as well.

See http://www.sun.com/961029/JES/whitepapers/javastation/javast_ch1.html
--
Barry Margolin
BBN Planet, Cambridge, MA

(BBN customers, please call (800) 632-7638 option 1 for support)



Mon, 19 Apr 1999 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

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

2. FWD>RE>Dylan mode for Emacs

3. VRML->Java->C++ ?

4. MIDI->JAVA->VRML

5. Calling Java from Dylan

6. Dylan to Java/JVM compiler?

7. Dylan to Java?

8. (HD) Java Dylan interoperability

9. Dylan Java Source Code Comparison

10. More on Java vs Dylan

11. Java-to-Dylan

12. java chips useful for dylan?

 

 
Powered by phpBB® Forum Software