Re: Do we really need virtual machines?

"Basile Starynkevitch \[news\]" <basile-news@starynkevitch.net>
4 Oct 2004 00:39:41 -0400

          From comp.compilers

Related articles
Do we really need virtual machines? Nicola.Musatti@ObjectWay.it (2004-10-02)
Re: Do we really need virtual machines? samiam@moorecad.com (Scott Moore) (2004-10-02)
Re: Do we really need virtual machines? dobes@dobesland.com (Dobes Vandermeer) (2004-10-02)
Re: Do we really need virtual machines? Juergen.Kahrs@vr-web.de (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=) (2004-10-02)
Re: Do we really need virtual machines? basile-news@starynkevitch.net (Basile Starynkevitch \[news\]) (2004-10-04)
Re: Do we really need virtual machines? joanpujol@gmail.com (Joan Pujol) (2004-10-04)
Re: Do we really need virtual machines? samiam@moorecad.com (Scott Moore) (2004-10-04)
Re: Do we really need virtual machines? slimick@venango.upb.pitt.edu (John Slimick) (2004-10-04)
Re: Do we really need virtual machines? nmm1@cus.cam.ac.uk (2004-10-09)
Re: Do we really need virtual machines? dot@dotat.at (Tony Finch) (2004-10-09)
Re: Do we really need virtual machines? Nicola.Musatti@ObjectWay.it (2004-10-09)
[9 later articles]
| List of all articles for this month |

From: "Basile Starynkevitch \[news\]" <basile-news@starynkevitch.net>
Newsgroups: comp.compilers
Date: 4 Oct 2004 00:39:41 -0400
Organization: http://starynkevitch.net - Ours
References: 04-10-013 04-10-037
Keywords: VM
Posted-Date: 04 Oct 2004 00:39:41 EDT

On 2004-10-02, Jürgen Kahrs <Juergen.Kahrs@vr-web.de> wrote:
> Nicola Musatti wrote:
>
>> According to their proponents virtual machines such as JVM and CLR
>> are the solution to all our (programming) problems, of which
>> portability is but one. [...]
>
> Has anyone ever noticed that the "standard libraries" that come with
> Java and C# are attempts to recreate Unix-like Operating Systems ?
> Including APIs for memory, file system, scheduler, terminal, printer,
> network, clock, GUI ... [....]
>
>> Now, this being the compiler forum, I'm interested in learning about
>> the advantages of virtual machines from the compiler writer
>> perspective.
>
> Our moderator (John) has pointed out _very_ often that language
> designers should first learn the lessons of the UNCOL period (1960s)
> before they start inventing yet another UNCOL-variant. Nobody listens
> to John; they are just too busy.


    I mostly agree with that comment, but I tend to believe that work
could still be done to define an intermediate language (not
necessarily a VM) for a common family of languages. For exemple, I
would believe that it could be possible to define an intermediate
language suitable to Ocaml and SML, and perhaps (possibly) also to
Scheme. This form won't be suitable to Java or Eiffel or C++ or C.


In other words, I would imagine that an intermediate form similar to
the "lambda" representation of the Ocaml compiler could be suitable
for SML and perhaps Scheme. Of course, the current "lambda"
representation is not it, but could be a little bit extended or
adapted.


All this is just a belief, not a result of hard work.


On a vaguely related note, I feel very sorry that JVM or CLR did not
evolve to incorrporate the few necessary features -notably closures &
tail recursive calls- to make them really usable for functional
languages like the ML family or Scheme. I suppose that the major
reason is not technical, but economical or political. (IIRC, some
relevant extensions to the JVM have been proposed by the functional
community but rejected by Sun).


    Regards/


Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France
[Common intermediate languages work OK if the source languages are
semantically similar and the targets are all about the same, e.g.
32 bit byte addressed twos-complement machines with flat addressing.
They collapse when you try to generalize them. -John]



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.