OCaml Documentation Request

[Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE>]

The Array.init and Array.make documentation says more or less the same:

====>
<<
  val init : int -> (int -> 'a) -> 'a array
>>
    
                Array.init n f returns a fresh array of length n,  with element
               number i initialized to the result of f i.  In other terms,
               Array.init n f tabulates the results of f  applied to the
               integers 0 to n-1.
               Raise Invalid_argument if n < 0 or n > Sys.max_array_length.  If
               the return type of f is float, then the maximum  size is only
               Sys.max_array_length / 2.
<====

Question: Is the statement about array max lengths accurate for 64-bit 
systems as well?


Request: The documentation does not mention the order in which the array 
is filled. Hence, the underlying implementation could do this 
last-to-first, first-to-last, or in some other crazy order. Of course, the 
presumably only reasonable way is to do it first-to-last, considering both
cache prefetch and similar issues at the bare metal level, and the 
principle of least surprise. However, this is not a guaranteed property, 
so one cannot use this in conjunction with code where application order 
does matter, e.g.:

let make_rx_decomposer nr_pieces rx_string =
  let rx = Str.regexp rx_string in
  fun str ->
    let rec walk so_far pos =
      let pos_found =
	try Str.search_forward rx str pos
	with 
	| Not_found -> (-1)
        (* This is a hack to maintain the niceties of
	   tail recursiveness (which exception handling
	   would destroy) without consing an int option.
	 *)
      in
      if pos_found=(-1)
      then List.rev so_far
      else
	let pos_end = Str.match_end() in
	let pieces_here =
	  Array.init nr_pieces 
	    (fun n -> Str.matched_group n str)
	in walk (pieces_here::so_far) pos_end
    in walk [] 0
;;

As it stands, this technique is not valid, as it uses non-guaranteed 
properties - the code "seems to work" anyway, however.

(But maybe, it sould be more appropriate to remove the implicit dependence 
on hidden state of some Str functions by providing a handle for such 
internal regexp-matcher state anyway.)

What's the opinion of the list on this issue?

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)