Version française
Home     About     Download     Resources     Contact us    
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 :
> tmp123@menta.net 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 List.map).
>
> 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

Christophe