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 RAA13684; Sun, 21 Mar 2004 17:11:04 +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 RAA14527 for ; Sun, 21 Mar 2004 17:11:02 +0100 (MET) Received: from pecan.cc.columbia.edu (pecan.cc.columbia.edu [128.59.59.178]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i2LGBXKW016238 for ; Sun, 21 Mar 2004 17:11:34 +0100 Received: from columbia.edu (tw304h3.cpmc.columbia.edu [156.111.84.180]) (user=ot14 mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i2LGAvBM022641 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 21 Mar 2004 11:10:58 -0500 (EST) Message-ID: <405DBE78.5020609@columbia.edu> Date: Sun, 21 Mar 2004 11:10:32 -0500 From: Oleg Trott User-Agent: Mozilla Thunderbird 0.5 (X11/20040309) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Vanier CC: caml-list@inria.fr Subject: Re: [Caml-list] extensible records again References: <20040321062143.BE7D29BBA2@orchestra.cs.caltech.edu> <405D4D77.2030403@columbia.edu> <20040321084008.429279BBA2@orchestra.cs.caltech.edu> In-Reply-To: <20040321084008.429279BBA2@orchestra.cs.caltech.edu> Content-Type: text/plain; charset=us-ascii; 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 vanier:01 2004:99 analogy:01 python:01 guile:01 failwith:01 runtime:01 failwith:01 runtime:01 type-check:01 run-time:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 282 Michael Vanier wrote: >>Date: Sun, 21 Mar 2004 03:08:23 -0500 >>From: Oleg Trott >> >> >> >> >>Note that in a language like Scheme, users can not add new types other >>than by combining the primitives. So, I suppose you aren't really >>talking about language users, but those who extend the language. >> >> > >Exactly. The analogy I give is with a language like python, where you can >add new types at the C level. Of course, this can be done in e.g. PLT >scheme or guile or perl or ruby as well. > > > >>The obvious thing to do is to use polymorphic variants. E.g. >> >>(* "core language" *) >> >>let plus a b = >> match (a, b) with >> | (`Int x), (`Int y) -> `Int (x + y) >> (* ... *) >> | _ -> failwith "runtime type error: argument is not a number" >> >> >> >>> >>> >>> >>(* language exension example, adding "files" *) >> >>let open = function `File f -> open_file f | _ -> failwith "runtime type >>error: argument is not a file" >> >> >>HTH >>Oleg >> >> >> > >I don't know if I can do this. > If you mean that your program won't type-check, then yes, it will, e.g. let x = `Int 3 let y = `File f (* f is something that open_file accepts *) let z = plus x y let _ = open y let _ = open (plus x z) All of this will type check, and will give run-time "type" errors instead (as a dynamically typed language should) >I have a top-level "data" type which all >data objects must be instances of. So in the case above, "open" would be a >function which took an argument of type "data". The question is then: how >do I specify the "data" type without explicitly making it polymorphic? > > You simply don't need to declare "data" (which is trying to emulate Lisp's type T). 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"). HTH Oleg ------------------- 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