Threads question...

> "The threads library is implemented by time-sharing on a single
> processor. It will not take advantage of multi-processor machines.
> Using this library will therefore never make programs run faster.
> However, many programs are easier to write when structured as several
> communicating processes."
>
> However, the documentation states that the native threads library is
> implemented using the system's native threading. (POSIX threads, in my
> case)
>
> Is the quote above still consistent with the native threads implementation?

Basically, yes.
With posix threads (or windows threads), every caml thread is mapped
to a posix thread, but there is a global mutex which any caml thread
must obtain before running. This makes sure for instance that memory
allocation and GC work properly.
So no more than one caml thread may run simultaneously, and you don't
gain from multiple CPUs.

However, contrary to vmthreads, this restriction only applies while
executing caml code. If you call some C function, you may choose to
first release the global lock (caml_enter_blocking_section), letting
other caml threads work while you are on the C side. Don't forget to
call lock again (caml_leave_blocking_section) when returning, or you
will crash very soon.
    

GODI news: GODI for O'Caml 3.08

Associativity precedence for the user-defined operator.

> I've defined a set of new operetors, for instance:
>
> let ( /+/ ) = add_num   (where add_num is a function that added two sometype
>                       elements.)
>
> but I don't know if I can set associativity precedence for this operator,
> writing: el1 ( /+/ ) el2 ( /+/ ) el3 without parenthesis, what happens?

The easiest way to control associativity and precedence seems to be to
write a Camlp4 extension.  For example here is a Camlp4 extension I
wrote to create some left-associative ('LEFTA') ops:

open Pcaml

EXTEND
   expr: AFTER "apply"
   [ LEFTA
       [ e1 = expr; "map_with"; e2 = expr ->
           <:expr< List.map $e2$ $e1$ >>
       | e1 = expr; "iter_with"; e2 = expr ->
           <:expr< List.iter $e2$ $e1$ >>
       | e1 = expr; "filter_with"; e2 = expr ->
           <:expr< List.filter $e2$ $e1$ >>
       | e1 = expr; "concat_with"; e2 = expr ->
           <:expr< List.concat (List.map $e2$ $e1$) >>
       | e1 = expr; "apply_with"; e2 = expr ->
           <:expr< $e2$ $e1$ >>
       ]
   ];
END
    

Bigarray is a pig

I have been looking at the sources of the Bigarray implementation.  I am
chagrined to discover that not only does Bigarray cost a function call
per array element access, but a number of additional piggish things
happen per access.  To C/C++ programmers interested in performance, this
defeats the purpose of using unboxed array elements.  If I wanted to pay
function call overhead per element, for instance when communicating with
OpenGL, I'd simply call functions.

I am wondering if there is some way to present a block of C memory to
OCaml, and then have OCaml use it directly?  If so, I could envision
writing up something I'd call 'Fastarray'.  But I'm interested in any
pitfalls you might see, such as range check requirements.

In other news, I've been trying and trying to announce the next ML
S*attle meeting on Tuesday, July 27th.   E-mail me for details.  These
anti-spam filters are maddening.
    

GNU source-highlight supports Caml and SML