Re: [Caml-list] extensible records again

[Michael Vanier <mvanier@cs.caltech.edu>]

> Date: Sun, 21 Mar 2004 11:10:32 -0500
> From: Oleg Trott <oleg_trott@columbia.edu>
> 
> Michael Vanier wrote:
> 
> >>Date: Sun, 21 Mar 2004 03:08:23 -0500
> >>From: Oleg Trott <oleg_trott@columbia.edu>
> >>
> >>
> >>    
> >>
> >>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