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: camlp4 revised syntax
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Christophe Raffalli <Christophe.Raffalli@u...>
Subject: Re: unboxed scalars - was [Caml-list] caml: camlp4 revised syntax
Basile STARYNKEVITCH a écrit :
> wrote:
>> Hello,
>> First of all, thanks to all people who develops this language and 
>> related tools, and to people who supports them using it.
>> I decided to use it in several developments. When finished, the 
>> developed modules will be made public, if they are enough generic 
>> (best place to publish it?)
>> Two points still causing some troubles:
>> 1) The internal integer coding:
>> It seems that an integer of value "x" is internally stored like 
>> "2x*1" ( x shift 1 or 1 ). That is a loss of performance, not only 
>> when doing calculations, but also, by example, when using the integer 
>> as index of a string character, ... . Usage of native-int doesn't 
>> improves the subject.
> This is unlikely to change any soon. It is (nearly) required by 
> polymorphic functions (like
> Changing it would require a very major change of the compiler, which 
> should specialize all polymorphic functions for such unboxed scalar 
> types. If it was done, it would require either a whole program 
> compilation, or a possible (exponential) bloat of generated code size 
> (basically for each polymorphic function, you would have to generate 
> all the scalar forms in addition of the polymorphic one).
Just look at MLTon, everything is monomorphised (and defunctorized) 
before generating assembly code ... and it works, because polymorphic 
functions are used
in fact with a very small set of types (often one !)  and only small  
function like map are used with many type ... So MLTon way may be the 
future of ML