caml: camlp4 revised syntax

caml: camlp4 revised syntax

[tmp123]

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.

2) Syntax:

It seems better to use the camlp4 revised syntax than the usual one. The 
reason is, by example, to skip this kind of errors:

initial version:
a1;
a2;
a3;
...

change to forget all exceptions produced by "a1": next source is 
incorrect with normal syntax (at execution time), but correct with 
revised one:

try
  a1
with
  _ -> ();
a2;
a3;

However, the revised syntax has a paradox. An "if" statement is, usually:

if ... then (
...
) else (
...
)

while a "for" statement can be:

for ... do
...
done

or

for ... do {
...
}

but not the expected one:
for ... (
)

why not a "for" that, as "let", "if" or "value", applies only to the 
next statment (or grouped list of them)? Knows someone if it is very 
dificult to modify the syntax to accept this?

Thanks again.

PS: direct mail to this address is filtered. To skip the filter, add 
word "caml" to the subject of the mail.

Re: unboxed scalars - was [Caml-list] caml: camlp4 revised syntax

[Basile STARYNKEVITCH]

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).

I'm not an Ocaml implementation expert, so I could be wrong, and I would be delighted to be confirmed or infirmed by the 
Ocaml guru implementors (e.g. Xavier Leroy).

IIRC, the ML/Ton implementation is rumored to do this kind of unboxing.

Besides, I am pretty sure than on current processors, unboxing scalars is probably more a win because of memory & cache 
issues than because of the additional shift & add required to transform a 2n+1 into n or vice versa. Such ALU operations 
are very cheap today.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net | mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: unboxed scalars - was [Caml-list] caml: camlp4 revised syntax

[Gerd Stolpmann]

Am Sonntag, den 15.07.2007, 13:42 +0200 schrieb Basile STARYNKEVITCH:
> Besides, I am pretty sure than on current processors, unboxing scalars is probably more a win because of memory & cache 
> issues than because of the additional shift & add required to transform a 2n+1 into n or vice versa. Such ALU operations 
> are very cheap today.

Absolutely. Given that any non-trivial program spends 20-40% of its time
in garbage collection, the net effect is probably positive, i.e. the GC
becomes more faster because of the tagged int representation than the
additional ALU cycles cost. (Any unboxing without tagging will make the
GC algorithm more complex and thus slower.)

You don't see this net effect in too simplistic benchmarks since you
need test programs of certain complexity.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------

Re: unboxed scalars - was [Caml-list] caml: camlp4 revised syntax

[Christophe Raffalli]

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
 

Re: [Caml-list] caml: camlp4 revised syntax

[Richard Jones]

On Sun, Jul 15, 2007 at 12:48:42PM +0200, tmp123@menta.net wrote:
> 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.

The cost is not as great as you think:

http://caml.inria.fr/pub/ml-archives/caml-list/2004/07/e86a25aa6c6a6a7d08dd7eb50cfd5d52.en.html

You also need to take into account the benefit of this representation
in other areas (eg. the GC).  Let's see you compare the performance of
real programs before jumping to conclusions.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] caml: camlp4 revised syntax

[Jon Harrop]

On Sunday 15 July 2007 11:48:42 tmp123@menta.net wrote:
> 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 a trade-off, of course. You can use untagged but usually boxed ints in 
OCaml via the Int32 module.

> 2) Syntax:
>
> It seems better to use the camlp4 revised syntax than the usual one. The
> reason is, by example, to skip this kind of errors...

Such misunderstandings disappear when you use auto indentation in emacs.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e

dml

[tmp123]

Hello,

In order to have an "eval" function, I'm trying to compile "dml".

Two problems have appeared up to now. For the first one I've solution, 
but not for the second one. Any help will be welcome.

1)
The first problem has appeared in the "configure" file of this package. 
The result of "ocaml -v" is "3.10.0". When "configure" executes the line:

OCAML_MINOR=$(echo $OCAMLVER | cut -d '.' -f 2)

the variable takes a vlue of "0", instead of "10".

The problem can be skip changing the previous line to:

OCAML_MINOR=$(echo $OCAMLVER | cut -d '.' -f 2)



2) When executing "make", the following error appears:

ocamlc -pp \
         "camlp4 -I /usr/local/lib/ocaml/camlp4 pa_o.cmo pa_extend.cmo 
q_MLast.cmo pr_dump.cmo -impl " \
         -I /usr/local/lib/ocaml/camlp4 -I ../rtcg  -c -impl dml.ml4

File "dml.ml4", line 82, characters 56-65:
While expanding quotation "expr" in a position of "expr":
   Parse error: [ctyp] expected after "(" (in [ctyp])

where the related line is the line "Some s -> ..." of:

let build_patt_fun loc body = function
     SimplePatt (Some id) ->
       <:expr< fun $lid:id$ -> $body$ >>
   | SimplePatt None ->
       <:expr< fun _ -> $body$ >>
   | TuplePatt l ->
       let tuple_id, new_body, typ = gen_tuple_patts loc body l in
       (match tuple_id with
         None ->  <:expr< fun _ -> $body$ >>
       | Some s -> <:expr< fun ( $lid:s$ : Rtcg.code ($list:typ$))
           -> $new_body$ >>)


No idea of where is the error here.

Thanks a lot.