Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] ANNOUNCE: mod_caml 1.0.6 - includes security patch
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Brian Hurt <bhurt@s...>
Subject: Re: [Caml-list] ANNOUNCE: mod_caml 1.0.6 - includes security patch
On Tue, 20 Jan 2004, Michal Moskal wrote:

> Haskell is lazy, ocaml is strict. Consider following snippet of
> ``ocaml'':
> 
> let _ = f (x)
>   where x = g ()
> 
> Now, the reader of the code might take false impression that f() is
> executed before g(). Of course there is no such danger with function
> definitions in where blocks, but still I think readability is the reason
> it is absent from ocaml.
> 

That peice of code would be equivelent to:
let _ =
    let x = g () in
    f x
;;

So precision isn't lost, just hidden.

I would think the following might be more of a problem:

let x = ... ;;

let _ = f x 
(* at this point, does the compiler know which x to use? *)
where x = g ()
;;

Even more hideous possibilities arise:

let rec f x = 
    let x = f (x + 3) 
    in 
    f (2 * x) 
    where f x = 2 + (f x) 
    and x = 3
;;

I admit that I can't follow which fs and which xs are which, and what the
result of that function would be (it'd be typed int -> int, that is
clear).  Even a simple question like "does f 3 even terminate?" is not at 
all obvious, let alone what answer it'd return.

Rewritting it makes it more obvious:

let rec f x =
    let f x = 2 + (f x)
    and x = 3
    in
    let x = f (x + 3) in
    f (2 * x)
;;

Hmm.  Opps- I do have an infinite recursion, don't I?

The solution to the five-deep let clauses is to cut them out to be their 
own top-level functions.  Function calls aren't that expensive.  And Ocaml 
is very good (IMHO maybe even a little too aggressive) about inlining 
functions where it's worthwhile.  And doesn't necessarily inline inner 
functions automatically either.  In poking around in the assembler output 
of various ocaml code I've written, the compiler will often take a 
complicated inner function and compile it like a stand-alone function.
Function calls simply aren't that expensive.

But the point here is that you're not gaining anything by using inner 
functions vr.s outer functions.  If you've got a big, unmanageable 
function, hack it apart into smaller stand-alone subfunctions.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners