Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] extensible records again
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-03-21 (17:36)
From: Oleg Trott <oleg_trott@c...>
Subject: Re: [Caml-list] extensible records again
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 Archives:
Bug reports: FAQ:
Beginner's list: