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 XAA30491; Sun, 21 Mar 2004 23:34:08 +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 XAA29995 for ; Sun, 21 Mar 2004 23:34:07 +0100 (MET) Received: from swordfish.cs.caltech.edu (swordfish.cs.caltech.edu [131.215.44.124]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i2LMYcKW013962 for ; Sun, 21 Mar 2004 23:34:39 +0100 Received: from orchestra.cs.caltech.edu (orchestra.cs.caltech.edu [131.215.44.20]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id D7B54DF260; Sun, 21 Mar 2004 14:34:03 -0800 (PST) Received: by orchestra.cs.caltech.edu (Postfix, from userid 2554) id 392519BBA2; Sun, 21 Mar 2004 14:34:01 -0800 (PST) From: Michael Vanier To: oleg_trott@columbia.edu Cc: caml-list@inria.fr In-reply-to: <405DBE78.5020609@columbia.edu> (message from Oleg Trott on Sun, 21 Mar 2004 11:10:32 -0500) 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> Message-Id: <20040321223401.392519BBA2@orchestra.cs.caltech.edu> Date: Sun, 21 Mar 2004 14:34:01 -0800 (PST) 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; vanier:01 mvanier:01 caml-list:01 extensible:01 2004:99 oleg:01 oleg:01 vanier:01 2004:99 analogy:01 python:01 guile:01 failwith:01 runtime:01 failwith:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 288 > Date: Sun, 21 Mar 2004 11:10:32 -0500 > From: Oleg Trott > > 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 > If I understand you correctly, then you're arguing that *all* my "core types" should be implemented using polymorphic variants. This is an interesting idea, which I'll consider. I think the problems I'm having have a lot to do with trying to mix polymorphic and regular variant types, which seems somewhat unnatural anyway. Mike ------------------- 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