From: mct
Subject: Is the Java VM language-independent or not?
Date: Tue, 05 Dec 1995 00:00:00 +0000
Message-ID: <1995Dec5.092155.20813@indyvax.iupui.edu>
	It is clearly a Good Thing for us to be able to use whatever
high level language we want, and compile it into Java Bytecodes.

Of course, the "memory model" of the chosen language must be
compatible with the JVM.  Because the JVM must be secure against
Thus, the obvious C's memory model is out.  (You **can**, however,
have a very C like source language, and compile to JVM.   Sun had a
"C" to Postscript compiler!  Yes, you lose pointer arithmetic, but
you can keep structures and arrays.)

So, to all you JVM experts,

*******************************************

WHAT'S IN THE JVM TO PREVENT US COMPILING FROM SCHEME OR ML?

*******************************************

Let's get the JVM right before the concrete sets!

-- Mark

I guess I'm just old fashioned. My mother always told me that
if you make a boxed value virtual machine, you can run any modern language,
from Basic to Scheme to ML Sather and  Modula3 (minus pointer arithmetic).

(I'm tired of having languages forced down my throat. Be honest,
and give me a virtual machine.)
--
==============================================================
Mark Tucker			········@regenstrief.iupui.edu
Regenstrief Institute		phone: (317) 630-2606
1001 W. 10'th St; Indianapolis, IN; 46202-2859;	fax: (317) 630-6962

From: Anselm Baird_smith
Subject: Re: Is the Java VM language-independent or not?
Date: Tue, 05 Dec 1995 00:00:00 +0000
Message-ID: <ABAIRD.95Dec5164452@houdon.inria.fr>
In article <·····················@indyvax.iupui.edu> ···@ (mct) writes:

> Newsgroups: comp.lang.java,comp.lang.scheme,comp.lang.lisp,gnu.misc.discuss,comp.lang.misc
> From: ···@ (mct)
> Date: 5 Dec 95 09:21:54 -0500
> Organization: I need to put my ORGANIZATION here.
>
> 	WHAT'S IN THE JVM TO PREVENT US COMPILING FROM SCHEME OR ML?

From my own experience, as a Scheme VM implementor, there is one thing
that I would lack: the ability to save function environments to the
heap (although I might be biased by my own implementation
technic). What I do is the following:

i)  all function environment are built into the stack (as in C),
ii) when a function gets closed, copy the env from the stack to the
heap, and build the closure.

This has some (alot ?) impact on the VM instruction set, although you
could still (as someone mentioned) implement Scheme in Java (have a
look at ftp://koala.inria.fr/pub/abs/java/* for a lisp like language
in Java), but it would not be efficient (ie compete with current
Scheme implementations).

I would like to be able to argue more on the necessity of i) and ii)
although I am afraid the only real argument I have is 'experimental',
so if someone has a better idea, I would like to hear it !

Anselm.
BTW: of course, call/cc would be another problem.
From: Pierre Parquier
Subject: Re: Is the Java VM language-independent or not?
Date: Wed, 06 Dec 1995 00:00:00 +0000
Message-ID: <PARQUIER.95Dec6111056@halles.ilog.fr>
In article <·····················@indyvax.iupui.edu> ···@ (mct) writes:

WHAT'S IN THE JVM TO PREVENT US COMPILING FROM SCHEME OR ML?

I don't know about JVM internals, but if you're thinking of the
broader issue: "What's prevents us from compiling from Scheme or ML to
JVM?", I found an interesting statement in "The Java Language
Environment, A white Paper", from James Gosling and Henry McGilton,
Sun Microsystem, May 1995, section "4.2 Security in the Java
Environment":

What about the concept of a "hostile compiler"?  [...] the
code may not have been produced by a known-to-be trustworthy
Java compile. [...] The answer is simple -- [Java run-time
system] doesn't trust the incoming [byte] code, but subjects
it to byte code verification.

The byte code verifier is shortly discribed (1 page) in that paper.

This statement implies that the availability of JVM on the Web is
meant to be restricted by this "byte code verifier", whose role is to
check that you're not trying to use the JVM running on the Web for
anything else than strict Java code.  Given the Web market orientation
of Java, this restriction makes a lot of sense.

So you should not think of running you Scheme code as JVM code on the
Web!

Since you cannot use JVM Web implementations to run your Scheme, then
why would you bother compiling Scheme to JVM?  Or is there some hope
this restriction can be raised?

Pierre
From: Ajit George
Subject: Re: Is the Java VM language-independent or not?
Date: Thu, 07 Dec 1995 00:00:00 +0000
Message-ID: <4a72dd$p5f@growl.cs.utexas.edu> Pierre Parquier (········@halles.ilog.fr) wrote: : In article <·····················@indyvax.iupui.edu> ···@ (mct) writes: : WHAT'S IN THE JVM TO PREVENT US COMPILING FROM SCHEME OR ML? : I don't know about JVM internals, but if you're thinking of the : broader issue: "What's prevents us from compiling from Scheme or ML to : JVM?", I found an interesting statement in "The Java Language : Environment, A white Paper", from James Gosling and Henry McGilton, : Sun Microsystem, May 1995, section "4.2 Security in the Java : Environment": : What about the concept of a "hostile compiler"? [...] the : code may not have been produced by a known-to-be trustworthy : Java compile. [...] The answer is simple -- [Java run-time : system] doesn't trust the incoming [byte] code, but subjects : it to byte code verification. : The byte code verifier is shortly discribed (1 page) in that paper. : This statement implies that the availability of JVM on the Web is : meant to be restricted by this "byte code verifier", whose role is to : check that you're not trying to use the JVM running on the Web for : anything else than strict Java code. Given the Web market orientation : of Java, this restriction makes a lot of sense. I think you're mistaken here. The description of the byte code verifier (provided below) implies that it wants to make sure that the bytecode is secure. It doesn't really matter where it comes from. ------------------------------------------------------------------------ From http://java.sun.com/whitePaper/java-whitepaper-8.html#HEADING8-8: ... the Java run-time system doesn't trust the incoming code, but subjects it to bytecode verification. The tests range from simple verification that the format of a code fragment is correct, to passing each code fragment through a simple theorem prover to establish that it plays by the rules: it doesn't forge pointers, it doesn't violate access restrictions, it accesses objects as what they are (for example, InputStream objects are always used as InputStreams and never as anything else). A language that is safe, plus run-time verification of generated code, establishes a base set of guarantees that interfaces cannot be violated. 6.2.1 The Byte Code Verifier The bytecode verifier traverses the bytecodes, constructs the type state information, and verifies the types of the parameters to all the bytecode instructions. [illustration describing separation of bytecode source from bytecode interpreter omitted] The illustration shows the flow of data and control from Java language source code through the Java compiler, to the bytecode verifier and hence on to the Java interpreter. The important issue is that the Java bytecode loader and the bytecode verifier make no assumptions about the primary source of the bytecode stream--the code may have come from the local system, or it may have travelled halfway around the planet. The bytecode verifier acts as a sort of gatekeeper: it ensures that code passed to the Java interpreter is in a fit state to be executed and can run without fear of breaking the Java interpreter. Imported code is not allowed to execute by any means until after it has passed the verifier's tests. Once the verifier is done, a number of important properties are known: There are no operand stack overflows or underflows The types of the parameters of all bytecode instructions are known to always be correct Object field accesses are known to be legal--private, public, or protected From: Allyn Dimock Subject: Re: Is the Java VM language-independent or not? Scheme support Date: Thu, 07 Dec 1995 00:00:00 +0000 Message-ID: <4a76qn$soe@necco.harvard.edu>
In a talk at MIT on Dec 6, Guy Steele said that he had a mandate from the
other Java developers to make sure that the Java VM would support Scheme.

I'm not sure of Steele's exact phrasing, and I may have missed any details
presented during the Q&A period after the official talk.

-- Allyn
From: Joe Buck
Subject: Re: Is the Java VM language-independent or not?
Date: Fri, 08 Dec 1995 00:00:00 +0000
Message-ID: <4aa3f3$4l4@hermes.synopsys.com> ········@halles.ilog.fr (Pierre Parquier) writes: .section "4.2 Security in the Java Environment": . What about the concept of a "hostile compiler"? [...] the . code may not have been produced by a known-to-be trustworthy . Java compile. [...] The answer is simple -- [Java run-time . system] doesn't trust the incoming [byte] code, but subjects . it to byte code verification. >The byte code verifier is shortly discribed (1 page) in that paper. >This statement implies that the availability of JVM on the Web is >meant to be restricted by this "byte code verifier", whose role is to >check that you're not trying to use the JVM running on the Web for >anything else than strict Java code. Your conclusion doesn't follow from your argument. The verifier is testing for violations of the security model. It is not trying to test whether or not a Java compiler produced the code. There is nothing to prevent a Scheme compiler from producing byte codes that satisfy the byte code verifier, simply by making the generated code follow the rules. Strong typing can be satisfied by implementing all the Scheme types as derived classes from a common base class. That's pretty much all you need. -- -- Joe Buck <·····@synopsys.com> (not speaking for Synopsys, Inc) From: Daniel C. Wang Subject: Re: Is the Java VM language-independent or not? Scheme support Date: Sat, 16 Dec 1995 00:00:00 +0000 Message-ID: <YkoksNi00YUuQANd1W@andrew.cmu.edu> ·····@cerc.wvu.edu (Matthew Fuchs) writes: > ···@best.com wrote: > : In article <··········@necco.harvard.edu> ······@das.harvard.edu (Allyn Dimo\ > ck) writes: > : | In a talk at MIT on Dec 6, Guy Steele said that he had a mandate from the > : | other Java developers to make sure that the Java VM would support Scheme. > : | > > : I hope this doesn't mean support for call/cc. Supporting call/cc is > : nontrivial, and while there is some argument to be made that you want > : it in a system used for teaching CS and AI/CS research, the tradeoffs > : for supporting it are just poor for a system like Java. > > I disagree entirely. I find call/cc extremely useful. In any case, > if the Java compiler would use CPS, then call/cc becomes trivial, as > Andrew Appel has shown with SML/NJ. CPS also makes much more sense in > a concurrent, distributed environment. Stacks can be really > clunky in such an environment, especially when IPC really is > continuation passing. A CPS based Java engine would make life much > simpler. hmmm how do you use call/cc in Scheme? The only examples I've seen that seemed useful were either co-routines or threads, which can be provided with runtime support. BTW CPS translation alone doesn't buy you efficient call/cc implemenetations. SML/NJ does well because "stack" frames/activation records are all heap allocated and left to the GC to clean up.  From: Matthew Fuchs Subject: Re: Is the Java VM language-independent or not? Scheme support Date: Sat, 16 Dec 1995 00:00:00 +0000 Message-ID: <DJnxwM.5Ms@cerc.wvu.edu> ···@best.com wrote: : In article <··········@necco.harvard.edu> ······@das.harvard.edu (Allyn Dimock) writes: : | In a talk at MIT on Dec 6, Guy Steele said that he had a mandate from the : | other Java developers to make sure that the Java VM would support Scheme. : | : I hope this doesn't mean support for call/cc. Supporting call/cc is : nontrivial, and while there is some argument to be made that you want : it in a system used for teaching CS and AI/CS research, the tradeoffs : for supporting it are just poor for a system like Java. I disagree entirely. I find call/cc extremely useful. In any case, if the Java compiler would use CPS, then call/cc becomes trivial, as Andrew Appel has shown with SML/NJ. CPS also makes much more sense in a concurrent, distributed environment. Stacks can be really clunky in such an environment, especially when IPC really is continuation passing. A CPS based Java engine would make life much simpler. Matthew Fuchs ·····@cerc.wvu.edu http://www.cerc.wvu.edu/~fuchs From: Louis-D. Dubeau Subject: Re: Is the Java VM language-independent or not? Date: Thu, 07 Dec 1995 00:00:00 +0000 Message-ID: <LDD.95Dec7153445@step.polymtl.ca> >>>>> "PP" == Pierre Parquier <········@halles.ilog.fr> writes: PP> What about the concept of a "hostile compiler"? [...] PP> the code may not have been produced by a known-to-be PP> trustworthy Java compile. [...] The answer is simple -- [Java PP> run-time system] doesn't trust the incoming [byte] code, but PP> subjects it to byte code verification. [crunch] PP> This statement implies that the availability of JVM on the Web PP> is meant to be restricted by this "byte code verifier", whose PP> role is to check that you're not trying to use the JVM running PP> on the Web for anything else than strict Java code. Given the PP> Web market orientation of Java, this restriction makes a lot PP> of sense. The statement means that the verifier checks code to be sure _security_ is not compromised, not that the source code must be Java. As long as the language you use is as secure as Java (for example, no pointers) then it can be compiled into Java byte code and executed by the JVM. ldd -- Louis-Dominique Dubeau == ···@step.polymtl.ca == ·····@info.polymtl.ca -- -- Home page: http://step.polymtl.ca/~ldd/ From: Peter Ludemann Subject: Re: Is the Java VM language-independent or not? Date: Fri, 08 Dec 1995 00:00:00 +0000 Message-ID: <LUDEMANN.95Dec8090630@expernet26.expernet.com> In article <··········@cnn.Princeton.EDU> ···@franck.Princeton.EDU (Tim Hollebeek) writes: I heard that Java can't handle closures, which I'm not particularly interested in, but what is the Java equivalent of a function pointer? Is there such a beast? If not, I can think of several languages that could be very tough to translate. I ran into a similar situation with O2C, an Object-C-like language used for programming the O2 object database. The same functionality can be achieved by: Make a making a class containing the function (method) as a virtual method Create one subclass for each different function you want to pass around Create one instance of each subclass The caller passes the subclass instance (rather than a function pointer) The callee takes the superclass as its argument -- Peter Ludemann ········@expernet.com ExperNet phone: +1.408.327.4339 Systems Architect fax: +1.415.949.1395 KNS Project Leader 3945 Freedom Circle, Suite 240, Santa Clara CA 95054 From: Andreas Krall Subject: Re: Is the Java VM language-independent or not? Date: Fri, 08 Dec 1995 00:00:00 +0000 Message-ID: <4a80ku$88e@news.tuwien.ac.at>
In article <·····················@indyvax.iupui.edu>,
···@ (mct) writes:
>
>	It is clearly a Good Thing for us to be able to use whatever
>high level language we want, and compile it into Java Bytecodes.
>
>	Of course, the "memory model" of the chosen language must be
>compatible with the JVM.  Because the JVM must be secure against
..
It is much easier than you think. You don't have to worry about the byte
code, just compile C, Lisp, Prolog or your favourite language to Java and
let the Java compiler translate it to byte code. Sometimes it could be
more efficient to directly translate to byte code, but Java compilers
will get better opimization with time. The restrictions will only be
the limits of the byte code definititions
like 32 bit design, 256 local variables and 32k branch offsets, but also
this can only hurt performance.

Andi
--
····@complang.tuwien.ac.at               Andreas Krall
http://www.complang.tuwien.ac.at/andi/   Inst. f. Computersprachen, TU Wien
tel: (+431) 58801/4462                   Argentinierstr. 8/4/1851
fax: (+431) 5057838                      A-1040 Wien     AUSTRIA     EUROPE
From: Ted Dunning
Subject: Re: Is the Java VM language-independent or not?
Date: Fri, 08 Dec 1995 00:00:00 +0000
Message-ID: <TED.95Dec8105310@hellespont.crl.nmsu.edu>
In article <·····················@expernet26.expernet.com> ········@expernet26.expernet.com (Peter Ludemann) writes:

[to make a function pointer equivalent in java]...

Make a making a class containing the function (method) as a
virtual method

Create one subclass for each different function you want to
pass around Create one instance of each subclass

The caller passes the subclass instance (rather than a
function pointer)

The callee takes the superclass as its argument

and if you add instance variables to the sub-class, you have a
closure.
--
For my papers and software, look at
http://crl.nmsu.edu/users/CRLfolks/dunning.html
From: Bob Foster
Subject: Re: Is the Java VM language-independent or not?
Date: Sat, 09 Dec 1995 00:00:00 +0000
Message-ID: <4abvvp$4gj@cloner3.netcom.com> ···@crl.nmsu.edu (Ted Dunning) wrote: >and if you add instance variables to the sub-class, you have a >closure. I'm sorry to be dense, but could you elaborate? I think of a closure as binding the environment in which it is created. Bob From: Tim Hollebeek Subject: Re: Is the Java VM language-independent or not? Date: Fri, 08 Dec 1995 00:00:00 +0000 Message-ID: <4a87p9$ctt@cnn.Princeton.EDU>
In article <··········@news.tuwien.ac.at>,
Andreas Krall <····@complang.tuwien.ac.at> wrote:
>In article <·····················@indyvax.iupui.edu>,
>	···@ (mct) writes:
>>
>>	It is clearly a Good Thing for us to be able to use whatever
>>high level language we want, and compile it into Java Bytecodes.
>>
>>	Of course, the "memory model" of the chosen language must be
>>compatible with the JVM.  Because the JVM must be secure against
>..
>It is much easier than you think. You don't have to worry about the byte
>code, just compile C, Lisp, Prolog or your favourite language to Java and
>let the Java compiler translate it to byte code. Sometimes it could be
>more efficient to directly translate to byte code, but Java compilers
>will get better opimization with time. The restrictions will only be
>the limits of the byte code definititions
>like 32 bit design, 256 local variables and 32k branch offsets, but also
>this can only hurt performance.

I heard that Java can't handle closures, which I'm not particularly
interested in, but what is the Java equivalent of a function pointer?
Is there such a beast?  If not, I can think of several languages that
could be very tough to translate.
--
Tim Hollebeek      | Everything above is a true statement, for sufficiently
PChem Grad Student | false values of true.
Princeton Univ.    | ···@wfn-shop.princeton.edu
-------------------| http://wfn-shop.princeton.edu/~tim
From: Erik Corry
Subject: Re: Is the Java VM language-independent or not?
Date: Fri, 08 Dec 1995 00:00:00 +0000
Message-ID: <DJAC8M.1Mo@kroete2.freinet.de>
Tim Hollebeek (···@franck.Princeton.EDU) wrote:
: I heard that Java can't handle closures, which I'm not particularly
: interested in, but what is the Java equivalent of a function pointer?
: Is there such a beast?  If not, I can think of several languages that
: could be very tough to translate.

Can't you just create an interface that contains one static method which
has the signature of the function you want a pointer to? A pointer to
the function is just implemented as a pointer to an object that has a
class that implements this interface. Seems OK to me. The object can be
a subclass of Object.

Similarly you should be able to implement functions (as opposed to
methods) by creating a subclass of Object that implements the function
as a static method.

If you want a closure instead of a function pointer, you can just
introduce private members into the class you are using, and have the
method call the actual function with the correct parameters.

Am I overlooking some problem here?

--
Erik Corry ·······@inet.uni-c.dk
From: David Wald
Subject: Re: Is the Java VM language-independent or not?
Date: Sat, 09 Dec 1995 00:00:00 +0000
Message-ID: <WALD.95Dec9084404@woodpecker.lcs.mit.edu>
In article <··········@cloner3.netcom.com> Bob Foster
<······@ix.netcom.com> writes:
>···@crl.nmsu.edu (Ted Dunning) wrote:
>>and if you add instance variables to the sub-class, you have a
>>closure.
>
>I'm sorry to be dense, but could you elaborate? I think of a closure as
>binding the environment in which it is created.

That's the meaning at the programming language level, but if you're
looking at implementing closures in some abstract machine (whether
that be Java itself or the Java VM) all you need ability to package up
a finite set of environment values with a reference to a function in
question.  The assertion isn't that Java, as a language, has closures,
but that it has the components needed to make the translation fairly
easy (or at least as easy as the substitute for function pointers
mentioned earlier).  Your translator can translate, say

(...
(set! f (lambda (y) (x + y + z)))
...
(f 3)
...)

into (in something somewhere between Java and C++):

{
class closure_1 : public function_object {
protected: Object mx; Object mz;
public: closure_1(x, z) { mx = x; mz = z; }
public: Object call_this(y) { return mx + y + mz; }
}

...
f = new closure_1(x, z);
...
f.call_this(3)
...
}

-David

--
============================================================================
David Wald      http://theory.lcs.mit.edu/~wald/     ····@theory.lcs.mit.edu
============================================================================
From: Bob Foster
Subject: Re: Is the Java VM language-independent or not?
Date: Sat, 09 Dec 1995 00:00:00 +0000
Message-ID: <4ac9md$7dj@cloner3.netcom.com> ····@theory.lcs.mit.edu (David Wald) wrote: >In article <··········@cloner3.netcom.com> Bob Foster ><······@ix.netcom.com> writes: >>···@crl.nmsu.edu (Ted Dunning) wrote: >>>and if you add instance variables to the sub-class, you have a >>>closure. >> >>I'm sorry to be dense, but could you elaborate? I think of a closure as >>binding the environment in which it is created. > >That's the meaning at the programming language level, but if you're >looking at implementing closures in some abstract machine (whether >that be Java itself or the Java VM) all you need ability to package up >a finite set of environment values with a reference to a function in >question. [snip] >{ > class closure_1 : public function_object { > protected: Object mx; Object mz; > public: closure_1(x, z) { mx = x; mz = z; } > public: Object call_this(y) { return mx + y + mz; } > } > > ... > f = new closure_1(x, z); > ... > f.call_this(3) Gosh, thanks. Excellent example. A couple of comments: It doesn't work in the sense of binding to the calling environment when x and z are primitive values, not objects. This applies recursively with respect to values referred to by x and y. And it doesn't work in general in C++, because the references to x and z may no longer be valid when call_this() is called. Java seems to provide the minimal confluence of features (all objects are heap objects, automatic garbage collection) to enable closures in a practical sense. In C++, a "closure class" would be burdened with too many caveats. Bob From: Fernando D. Mato Mira Subject: Secure Scheme (was: Is the Java VM language-independent or not?) Date: Mon, 11 Dec 1995 00:00:00 +0000 Message-ID: <4ahrf8$92d@info.epfl.ch>
BTW, check also:

http://www.inria.fr/koala/abaird/oscheme/secure.html

--
Fernando D. Mato Mira			 http://ligwww.epfl.ch/matomira.html
Computer Graphics Lab
Swiss Federal Institute of Technology (EPFL)  Phone    : +41 (21) 693 - 5248
CH-1015 Lausanne			      FAX      : +41 (21) 693 - 5328
Switzerland				      E-mail   : ········@di.epfl.ch

From: Simon Brooke
Subject: Re: Secure Scheme (was: Is the Java VM language-independent or not?)
Date: Sat, 23 Dec 1995 00:00:00 +0000
Message-ID: <30DC6DE2.3D1BBD58@rheged.dircon.co.uk>
Hhhhmmmmm...

Fernando D. Mato Mira wrote:
>
> BTW, check also:
>
> http://www.inria.fr/koala/abaird/oscheme/secure.html

I did this. Nice information, but where do I get OScheme from?

--
------- ·····@rheged.dircon.co.uk (Simon Brooke)

...but have you *seen* the size of the world wide spider?
From: Fernando D. Mato Mira
Subject: Re: Secure Scheme (was: Is the Java VM language-independent or not?)
Date: Tue, 26 Dec 1995 00:00:00 +0000
Message-ID: <4bp5pl$nu4@info.epfl.ch> In article <·················@rheged.dircon.co.uk>, Simon Brooke <·····@rheged.dircon.co.uk> writes: |> > http://www.inria.fr/koala/abaird/oscheme/secure.html |> |> I did this. Nice information, but where do I get OScheme from? http://www.inria.fr/koala/abaird/oscheme/get.html -- Fernando D. Mato Mira http://ligwww.epfl.ch/matomira.html Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : ········@di.epfl.ch  From: Erik Corry Subject: Re: Is the Java VM language-independent or not? Date: Tue, 12 Dec 1995 00:00:00 +0000 Message-ID: <DJHAqF.1tr@kroete2.freinet.de> Bob Foster (······@ix.netcom.com) wrote: : ····@theory.lcs.mit.edu (David Wald) wrote: : > { : > class closure_1 : public function_object { : > protected: Object mx; Object mz; : > public: closure_1(x, z) { mx = x; mz = z; } : > public: Object call_this(y) { return mx + y + mz; } : > } : > : > ... : > f = new closure_1(x, z); : > ... : > f.call_this(3) : : Gosh, thanks. Excellent example. A couple of comments: It doesn't work : in the sense of binding to the calling environment when x and z are : primitive values, not objects. You can get around this fairly simply, but putting the primitive values in a container class. These classes are already predefined in Java. : This applies recursively with respect to values referred to by x and y. Does it? You can't have a reference to a primitive type, so you must mean primitive values that are members of x and y. But that would seem to me to work. -- Erik Corry ·······@inet.uni-c.dk From: MAEDA Atusi Subject: Re: Is the Java VM language-independent or not? Date: Mon, 11 Dec 1995 00:00:00 +0000 Message-ID: <MAD.95Dec11175346@emerald.math.keio.ac.jp> >>>>> "objfac" == Bob Foster <······@ix.netcom.com> writes: In article <··········@cloner3.netcom.com> Bob Foster <······@ix.netcom.com> writes: objfac> ···@crl.nmsu.edu (Ted Dunning) wrote: >> and if you add instance variables to the sub-class, you have a >> closure. objfac> I'm sorry to be dense, but could you elaborate? I think of a closure as objfac> binding the environment in which it is created. Closure is <private data> + <code accessing that data>, from implementational point of view. And so is instance. See, e.g. @techreport( 76Lambda, author = {Guy Lewis Steele Jr.}, title = {Lambda, the Ultimate Declarative}, year = 1976, month = nov, number = 379, type = {MIT AI Memo}, institution = {Massachusetts Institute of Technology}, address = {Cambridge, Mass.}, keywords = {declarative} ) in the section "Actors \equiv Closures (mod Syntax)". --mad From: Guillermo (Bill) J. Rozas Subject: Re: Is the Java VM language-independent or not? Scheme support Date: Thu, 14 Dec 1995 00:00:00 +0000 Message-ID: <GJR.95Dec14134636@hplgr2.hpl.hp.com> In article <···············@tmb.vip.best.com> ···@best.com () writes: | Reply-To: ···@best.com | In-reply-to: ······@das.harvard.edu's message of 7 Dec 1995 17:04:23 GMT | X-Newsreader: Gnus v5.0.4 | | In article <··········@necco.harvard.edu> ······@das.harvard.edu (Allyn Dimock) writes: | | In a talk at MIT on Dec 6, Guy Steele said that he had a mandate from the | | other Java developers to make sure that the Java VM would support Scheme. | | | | I'm not sure of Steele's exact phrasing, and I may have missed any details | | presented during the Q&A period after the official talk. | | I hope this doesn't mean support for call/cc. Supporting call/cc is | nontrivial, and while there is some argument to be made that you want | it in a system used for teaching CS and AI/CS research, the tradeoffs | for supporting it are just poor for a system like Java. I also hope | it doesn't mean Scheme's floating point stuff, which not even MIT | bothers to implement. Hah? In the context ot a simple VM like Java's, supporting cwcc is straight-forward. Even with compilation it is not hard. The hard issues have to do with inter-operability with C, since C code is typically not reentrant in this fashion. With respect to floating point, what do you mean that MIT does not implement it? There is really no floating-point in the Scheme standard/reports. Floating-point is an implementation technique for numbers that the standard works well with. As far as I know MIT's implementation is fully compliant with the standard and uses floating-point to represent some classes of numbers. MIT's is not the only implementation with this property. | Beyond that, there really is nothing that the Java VM needs to support | Scheme reasonably well. Tail recursion? From: ········@millcomm.com Subject: Re: Is the Java VM language-independent or not? Date: Fri, 15 Dec 1995 00:00:00 +0000 Message-ID: <4ar483$8d8@misery.millcomm.com>
In <···············@tmb.vip.best.com>, ···@best.com () writes:
>In article <·····················@halles.ilog.fr> ········@halles.ilog.fr (Pierre Parquier) writes:
>| 	What about the concept of a "hostile compiler"?  [...] the
>| 	code may not have been produced by a known-to-be trustworthy
>| 	Java compile. [...] The answer is simple -- [Java run-time
>| 	system] doesn't trust the incoming [byte] code, but subjects
>| 	it to byte code verification.
>|
>| The byte code verifier is shortly discribed (1 page) in that paper.
>|
>| This statement implies that the availability of JVM on the Web is
>| meant to be restricted by this "byte code verifier", whose role is to
>| check that you're not trying to use the JVM running on the Web for
>| anything else than strict Java code.  Given the Web market orientation
>| of Java, this restriction makes a lot of sense.
>|
>| So you should not think of running you Scheme code as JVM code on the
>| Web!
>|
>| Since you cannot use JVM Web implementations to run your Scheme, then
>| why would you bother compiling Scheme to JVM?  Or is there some hope
>| this restriction can be raised?
>
>You completely misunderstood the passage.  The byte code verifier is
>simply a type checker at the byte code level.  It doesn't care whether
>the source was written in Java, Scheme, or assembly, as long as the
>byte code is type correct.
>
>There is no restriction to be raised.

I haven't had a chance to take a close look at Java yet, and have not even had
a glimpse at the JVM definition, but in many ways it sounds similar to the IBM
AS/400 MI concept, and thus there are probably some things that can be learned
about the JVM concept by looking at the AS/400.

AS/400 has two basic MI (virtual Machine Interface) models.  The older, cruder
one is a storage-to-storage model, while the newer one is a stack model
distantly related to P-code.  In both models a "trusted translator" is used to
convert the MI code stream into an executable code stream, eliminating the
need for most storage protection mechanisms, etc.  This has worked quite well
(in conjunction with a "capability" pointer mechanism) though recently
hardware storage protection mechanisms have been added (largely to satisfy the
auditors passing on certification for the military C2 security
classification).  This "trusted translator" concept is not much different from
the concept of a trusted interpreter -- in both cases checks are made to
assure that the input stream can't do things it shouldn't.

One other point about the AS/400 MI (both versions) is that it incorporates a
call-return stack model and associated exception mechanisms.  I get the
impression that the JVM model does likewise, though that's just reading
between the lines of the posts here.  I think the built-in call-return support
is a good idea, even though it may cramp the style of some programmers.
I can't articulate what it does for you, but I sense that it enables a finer
grain of "filtering" -- making it possible to allow more accessible function
while maintaining a given degree of protection of the system.

Dan Hicks
A Christmas gift:  http://www.millcomm.com/~danhicks/Christmas.html