From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA18785; Sun, 21 Mar 2004 18:36:58 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 SAA17834 for ; Sun, 21 Mar 2004 18:36:57 +0100 (MET) Received: from brazilnut.cc.columbia.edu (brazilnut.cc.columbia.edu [128.59.59.203]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i2LHbSKW022636 for ; Sun, 21 Mar 2004 18:37:29 +0100 Received: from columbia.edu (tw304h3.cpmc.columbia.edu [156.111.84.180]) (user=ot14 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i2LHaoYu024099 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 21 Mar 2004 12:36:53 -0500 (EST) Message-ID: <405DD298.109@columbia.edu> Date: Sun, 21 Mar 2004 12:36:24 -0500 From: Oleg Trott User-Agent: Mozilla Thunderbird 0.5 (X11/20040309) X-Accept-Language: en-us, en MIME-Version: 1.0 To: skaller@users.sourceforge.net CC: Michael Vanier , caml-list Subject: Re: [Caml-list] extensible records again References: <20040321062143.BE7D29BBA2@orchestra.cs.caltech.edu> <405D4D77.2030403@columbia.edu> <20040321084008.429279BBA2@orchestra.cs.caltech.edu> <405DBE78.5020609@columbia.edu> <1079888775.3165.11.camel@pelican.wigram> In-Reply-To: <1079888775.3165.11.camel@pelican.wigram> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; oleg:01 oleg:01 caml-list:01 extensible:01 2004:99 vanier:01 refactor:01 vyper:01 python:01 compiler:01 compilers:01 ocaml:01 variants:01 int:01 int:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 285 skaller wrote: >On Mon, 2004-03-22 at 03:10, Oleg Trott wrote: > > >>Michael Vanier wrote: >> >> In fact, in your case, I believe it's more convenient >>not to create an artificial distinction between the "core types" and >>"other types": suppose someone extended your language with "files", and >>you later decide to add "file" to your "core types". You'll have to >>redefine "data" and refactor a lot of your base code to do it, unless >>you just use polymorphic variants, as suggested (in which case there is >>no special distinction between "core types" and "other types"). >> >> > >However there IS a reason for making the distinction sometimes, >namely performance. > >My Vyper interpreter (a Python interpreter written in Ocaml) > > ^^^^^^^^^^ Compared to the interpretation overhead, I don't think you'll see any difference in performance, not by a long shot. If I were writing a dynamically-typed language implementation in O'Caml, I'd _compile_ it _to_ O'Caml (as opposed to interpreting the language) In fact, except for EVAL and CALL/CC, it's probably very trivial to write a Scheme-to-OCaml compiler, and get the performance on par with decent native-code Scheme compilers. >used a type like > >type PyObject = Int of int | Float of float | >String of string | PyClass of pyclass > >which deliberately distinguished simple types >so that a fast match could be used to perform >common calculations: > >match o1, o2 with >| Int i, Int j -> Int (i + j) >.... > > > ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners