Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: OLabl bug?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques GARRIGUE <garrigue@k...>
Subject: Re: OLabl bug?
> I had originally sent this to the CAML mailing list, but I think, in
> restrospect, this should have been sent to you.
> 
> While goofing around with bignums, I entered the following program
> for computing a crude bound on the van der Waerden number for length
> 3 and partition 3.
> 
>    open Num
>    open Nat
>    open Big_int
>    open Ratio
> 
>    let rec n k l =
>      let rec m i =
>        if i =/ Int 0 then
>          Int 1 else
>          Int 2
>            */ (m (pred_num i))
>            */ (n (k **/ (m (pred_num i))) (pred_num l)) in
>      if l =/ Int 2 then succ_num k else m k
>    in
>      print_string (string_of_num (n (Int 3) (Int 3)));;
> 
> Pierre Weis tells me this is legal OCAML, but OLABL complains about
> a syntax error at the second in.  What can you tell me?

He is slightly wrong: your program as such will raise a syntax error
in ocaml also. He took me some time to find it, because I was always
pasting your input in two times: first the open statements, and then
the let in, and if you do that there is no error.

This is not an olabl bug, neither really an ocaml one.
The problem is that you are mixing two syntaxes: the one with
terminator (;;), and the one without (nothing after open).
Normally the first syntax is to be used at toplevel, and the second in
files, but there are hacks in the parser to allow a certain level
of mixing, which is confusing, I must admit.

Seeing a let immediatly after an open declaration, the parser is
waiting for a definitional let, and not a let in. So it throws you
when the pairing "in" comes.

Two solutions: either you add a terminator between the open sequence
and the let, or you add a dummy toplevel let:

let _ =
  let ... in ...

(The second one is the only possibility when writing compiled modules)

Cheers,

	Jacques