Question about try.. with

Question about try.. with

[christian konrad]

Hello list,

I'm doing that:

let _ =
  try
   let infile = open_in !filename in
   let rec readIn () =
      try
         (input_line infile) ^ readIn();
      with ee -> "";
   in
    print_string(readIn () );
   "good";
  with e -> "";;

So why don't I get any output at all? Doesn't "with" erease the raised 
Exception?

Thanks and cheers, chris

Re: [Caml-list] Question about try.. with

[Jon Harrop]

On Saturday 17 February 2007 23:40, christian konrad wrote:
> Hello list,
>
> I'm doing that:
>
> let _ =
>   try
>    let infile = open_in !filename in
>    let rec readIn () =
>       try
>          (input_line infile) ^ readIn();
>       with ee -> "";
>    in
>     print_string(readIn () );
>    "good";
>   with e -> "";;
>
> So why don't I get any output at all? Doesn't "with" erease the raised
> Exception?

You may get better/faster responses to this kind of question on the beginners 
list. Reading a file is a FAQ and the stdlib does little to help.

In this case, your code is probably stack overflowing due to too much 
recursion, raising the Stack_overflow exception which is then caught and the 
empty string returned.

To circumvent this problem (and the fact that repeated string concatenation is 
slow) you should write that function in the following style:

(* Boxed input_line *)
let try_input_line ch =
  try Some(input_line ch) with End_of_file -> None;;

(* Left fold over lines in a file. *)
let rec fold_lines f accu ch =
  match try_input_line ch with
  | None -> accu
  | Some string -> fold_lines f (f accu string) ch;;

(* Ensure that something is done after completion, whether or not an exception
   was raised. *)
let finally f x g y =
  try
    let f_x = f x in
    g y;
    f_x
  with exn ->
    g y;
    raise exn;;

(* Apply a function "k" to a file, ensuring that the file gets closed *)
let read file k =
  let ch = open_in file in
  finally k ch close_in ch;;

(* Read the lines of a file. *)
let _ =
  let lines = List.rev (read file (fold_lines (fun t h -> h::t) [])) in
  let file = String.concat "\n" lines in
  print_endline file;;

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

Re: [Caml-list] Question about try.. with

[Geoffrey Romer]

> You may get better/faster responses to this kind of question on the beginners
> list. Reading a file is a FAQ and the stdlib does little to help.

Is there a way to join the beginner's list that doesn't require having
a Yahoo account? The link from the "Forums" page on caml.inria.fr goes
to Yahoo, and seems to imply you need a Yahoo membership to subscribe.

Re: [Caml-list] Question about try.. with

[Christophe TROESTLER]

On Sat, 17 Feb 2007, "Geoffrey Romer" <geoff.romer@gmail.com> wrote:
> 
> Is there a way to join the beginner's list that doesn't require having
> a Yahoo account? The link from the "Forums" page on caml.inria.fr goes
> to Yahoo, and seems to imply you need a Yahoo membership to subscribe.

Send an email to ocaml_beginners-subscribe@yahoogroups.com

ChriS

Re: [Caml-list] Question about try.. with

[Jacques Garrigue]

From: christian konrad <konrad@in.tum.de>

> I'm doing that:
> 
> let _ =
>   try
>    let infile = open_in !filename in
>    let rec readIn () =
>       try
>          (input_line infile) ^ readIn();
>       with ee -> "";
>    in
>     print_string(readIn () );
>    "good";
>   with e -> "";;
> 
> So why don't I get any output at all? Doesn't "with" erease the raised 
> Exception?

Because you assume wrongly that input_line will be called before the
recursive call to readIn. Nothing in the ocaml specification says so
(evaluation order is left undefined.) In practice the rightmost call
is done first, which is the recursive call here, but you shouldn't
depend on it either.
By the way, it is a bad idea to catch all exceptions. ee should be
End_of_file and e should be Sys_error _.

Jacques Garrigue

Re: [Caml-list] Question about try.. with

[christian konrad]

Thanks for all those hints. For the future I will use the beginners 
list, thank you.
But that seams really strange not to have a strictly defined order of 
evaluation. Isn't that really bad if one would like to do some tail 
recursion to get it compiled without recursion but as a loop?

Thanks and cheers,

Chris

Jacques Garrigue wrote:

>From: christian konrad <konrad@in.tum.de>
>
>  
>
>>I'm doing that:
>>
>>let _ =
>>  try
>>   let infile = open_in !filename in
>>   let rec readIn () =
>>      try
>>         (input_line infile) ^ readIn();
>>      with ee -> "";
>>   in
>>    print_string(readIn () );
>>   "good";
>>  with e -> "";;
>>
>>So why don't I get any output at all? Doesn't "with" erease the raised 
>>Exception?
>>    
>>
>
>Because you assume wrongly that input_line will be called before the
>recursive call to readIn. Nothing in the ocaml specification says so
>(evaluation order is left undefined.) In practice the rightmost call
>is done first, which is the recursive call here, but you shouldn't
>depend on it either.
>By the way, it is a bad idea to catch all exceptions. ee should be
>End_of_file and e should be Sys_error _.
>
>Jacques Garrigue
>
>  
>

Re: [Caml-list] Question about try.. with

[Andrej Bauer]

christian konrad wrote:
> But that seams really strange not to have a strictly defined order of 
> evaluation. Isn't that really bad if one would like to do some tail 
> recursion to get it compiled without recursion but as a loop?

Undefined order of evaluation allows more optimization.

Arguably, it may be confusing for the programmer (especially one who is 
used to relying on order of evaluation of arguments to a function 
call--a rather dangerous practice). But your remark about tail recursion 
is mistaken, i.e., you are suggesting that a call to a function inside 
an argument to another function might be tail-recursive, which is 
clearly impossible.

In your example, you had

   let rec readIn() =
      ....
      (input_line infile) ^ readIn()
      ....

Here we have arguments "input_line infile" and "readIn()" to the binary 
operation ^. It does not matter what the order of evaluation of the 
arguments is: readIn cannot be tail-recursive under any order, since the 
last thing that needs to happen is ^.

Best regards,

Andrej