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