Browse thread
caml: camlp4 revised syntax
-
tmp123@m...
-
Basile STARYNKEVITCH
- Gerd Stolpmann
- Christophe Raffalli
- Richard Jones
- Jon Harrop
-
Basile STARYNKEVITCH
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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