From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA27584 for caml-redistribution; Mon, 11 Oct 1999 19:26:31 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA01939 for ; Mon, 11 Oct 1999 01:54:18 +0200 (MET DST) Received: from nef.ens.fr (nef.ens.fr [129.199.96.12]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id BAA27185 for ; Mon, 11 Oct 1999 01:54:16 +0200 (MET DST) Received: from clipper.ens.fr (clipper-gw.ens.fr [129.199.1.22]) by nef.ens.fr (8.9.3/beig-1.0) with ESMTP id BAA16113 for ; Mon, 11 Oct 1999 01:54:16 +0200 (MET DST) Received: from localhost (frisch@localhost) by clipper.ens.fr (8.8.7/jb-1.1) id BAA15032 for ; Mon, 11 Oct 1999 01:54:15 +0200 (MET DST) Date: Mon, 11 Oct 1999 01:54:15 +0200 (MET DST) From: Alain Frisch X-Sender: frisch@clipper To: caml-list@inria.fr Subject: Re: speed versus C In-Reply-To: <24949.199910102048@buckie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: weis On Sun, 10 Oct 1999, William Chesters wrote: > My point was simply that nearly every* feature of ocaml, however > abstract in appearance, compiles directly, and compositionally, onto > an idiom which one might well use in C or even assembler---give or > take some amount of sugar. Looking at this fact one way round, I > * apart from GC and the ocaml classes (of which I must admit I am > slightly suspicious, because of the significant overhead in a method > call---you don't really want to use them in an inner loop) I would also add boxing/unboxing, and structural comparison to the list of important features which aren't well implemented in classical architecture. Do you think it would be easy to design processors with built-in support for boxed values, GC tags, OO, etc ... that is, a concrete OCaml machine ? -- Alain Frisch