Re: [Caml-list] Suggestion for Int32.rotate

[Xavier Leroy <xavier.leroy@inria.fr>]

> 2) A syntax extension (or extension to the standard syntax) for
> entering Int32 and Int64 constants. 

This has been on my to do list for a while.  The main issue is finding
a decent syntax...  (All discussions on this list seem to converge on
syntax these days, that's awful :-) We have three "big integer" types:
int32, nativeint and int64.  A C-style syntax would be 12345L for
int32 and 123456789LL for int64; what about nativeint?  12345N ?
Anything nicer?

> 3) A hack into Printf to remove the need to use Int32.format

Printf support was added in 3.04: "%ld", "%nd", "%Ld" for int32,
nativeint and int64 respectively.

> I.e. better support for int32's. I understand that the Caml team does
> not want people to use int32's (or int64's) by default.

It's not that we object to this, just that these types are boxed and
this impacts performance to some extent, so you're advised to use them
only when you need them (as you obviously do).

> However a lot
> of coding/crypto stuff, deserving to be ported to Caml, works with
> 32-bit ints and it would be good to be able to use them at full speed.
> For example, the MD5 routine used in Digest.string could be efficiently
> rewritten in Caml.

I played with a Caml reimplementation of MD5 a while ago, and even
with various source-level tweaks, ocamlopt isn't clever enough to
eliminate all boxing and unboxing.  The result is about 2-3 times
slower than hand-optimized C.

More generally speaking, I don't think basic ciphers and hash
functions really benefit from being rewritten in Caml.  C is extremely
painful as a general-purpose language, but OK for some things:
bytecode interpreters, memory managers, device drivers, crypto
primitives, ...  MD5 written in Caml isn't noticeably nicer / safer /
less buggy than MD5 in C.  So, why not just interface with existing C
implementations -- with the additional benefits that someone else
already debugged and performance-tweaked them?

Don't get me wrong: as soon as we move up from the crypto basic
blocks into real cryptographic protocols and applications, the
benefits of Caml (or other high-level languages) become obvious.
(I shudder at the idea of implementing a public-key infrastructure in C.)
It's just that basic blocks like MD5 or DES are, well, just basic
blocks -- just like integer addition; who cares how they are implemented
as long as they work?

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr