[Caml-list] let rec

[Caml-list] let rec

[Vitaly Lugovsky]

 For a closure-driven "compilers" I have to use for
a recursion something like this:

    let xprs = ref (fun _ -> Lnil) in
    let f (il,al,ht) =
      let il2 = Array.make (n2+1) Lnil in
      acopy il il2;
      Array.iteri (fun i x -> il2.(all.(i)) <- x) al;
      !xprs (il2,anul,ht)
    in xprs :=
      (Hashtbl.replace ht name (CTfun(f)); (* Insert f into the env2
                                              environment *)
       compile_exprs env2 exprs);
    f

 It's not so funny. Why I can't write it using let rec:

    let rec f (il,al,ht) =
      let il2 = Array.make (n2+1) Lnil in
      acopy il il2;
      Array.iteri (fun i x -> il2.(all.(i)) <- x) al;
      xprs (il2,anul,ht)
    and xprs =
      (Hashtbl.replace ht name (CTfun(f));
       compile_exprs env2 exprs) in
    f

 Sure, let rec construction should be much less restrictive.

 And, another one question: does ocaml compiler really eliminates
unused variables from the closure environment?

-------------------
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

Re: [Caml-list] let rec

[james woodyatt]

On Wednesday, Jan 15, 2003, at 11:15 US/Pacific, Vitaly Lugovsky wrote:
>
> let rec f (il,al,ht) =
>       let il2 = Array.make (n2+1) Lnil in
>       acopy il il2;
>       Array.iteri (fun i x -> il2.(all.(i)) <- x) al;
>       xprs (il2,anul,ht)
>     and xprs =
>       (Hashtbl.replace ht name (CTfun(f));
>        compile_exprs env2 exprs) in
>     f

I run into the same sort of problem all the time.  It's that 'let rec' 
requires the patten on the left to be a function (okay, there's a weird 
exception, but you don't care about it).

Try this:
	
     let rec f (il,al,ht) =
       let il2 = Array.make (n2+1) Lnil in
       acopy il il2;
       Array.iteri (fun i x -> il2.(all.(i)) <- x) al;
       xprs (il2,anul,ht)
     and xprs x =
       (Hashtbl.replace ht name (CTfun(f));
        compile_exprs env2 exprs) x in
     f


-- 
j h woodyatt <jhw@wetware.com>
that's my village calling... no doubt, they want their idiot back.

-------------------
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

Re: [Caml-list] let rec

[Vitaly Lugovsky]

On Wed, 15 Jan 2003, james woodyatt wrote:

> Try this:
>
>      let rec f (il,al,ht) =
>        let il2 = Array.make (n2+1) Lnil in
>        acopy il il2;
>        Array.iteri (fun i x -> il2.(all.(i)) <- x) al;
>        xprs (il2,anul,ht)
>      and xprs x =
>        (Hashtbl.replace ht name (CTfun(f));
>         compile_exprs env2 exprs) x in
>      f

 It's not a same implementation. :(

Hashtbl.replace should be executed only in the
"compilation-time", not after the closure
'f' call. And, ht and env2 should be eliminated completely from
the 'f' execution environment...

-------------------
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

Re: [Caml-list] let rec

[Max Kirillov]

On Wed, Jan 15, 2003 at 10:15:48PM +0300, Vitaly Lugovsky wrote:
VL>  It's not so funny. Why I can't write it using let rec:
VL> 
VL>     let rec f (il,al,ht) =
VL>       let il2 = Array.make (n2+1) Lnil in
VL>       acopy il il2;
VL>       Array.iteri (fun i x -> il2.(all.(i)) <- x) al;
VL>       xprs (il2,anul,ht)
VL>     and xprs =
VL>       (Hashtbl.replace ht name (CTfun(f));
VL>        compile_exprs env2 exprs) in
VL>     f

You may use lazy things:

>     let rec f (il,al,ht) =
>       let il2 = Array.make (n2+1) Lnil in
>       acopy il il2;
>       Array.iteri (fun i x -> il2.(all.(i)) <- x) al;
>       (Lazy.force xprs) (il2,anul,ht)
>     and xprs =
>       lazy ((Hashtbl.replace ht name (CTfun(f));
>		compile_exprs env2 exprs)) in
>     (*optional*) ignore(Lazy.force xprs);
>     f

-- 
Max
-------------------
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

Re: [Caml-list] let rec

[Mike Potanin]

On Wed, 15 Jan 2003, Vitaly Lugovsky wrote:

>  It's not so funny. Why I can't write it using let rec:
>
>     let rec f (il,al,ht) =
>       let il2 = Array.make (n2+1) Lnil in
>       acopy il il2;
>       Array.iteri (fun i x -> il2.(all.(i)) <- x) al;
>       xprs (il2,anul,ht)
>     and xprs =
>       (Hashtbl.replace ht name (CTfun(f));
>        compile_exprs env2 exprs) in
>     f
>
>  Sure, let rec construction should be much less restrictive.
The similar problem arises in a case
let ring l = let rec r = l@r in r
OCaml type system can not understand that the design is safe.
>
>  And, another one question: does ocaml compiler really eliminates
> unused variables from the closure environment?
>
> -------------------
> 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
>

-------------------
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

Re: [Caml-list] let rec

[Damien Doligez]

On Thursday, January 16, 2003, at 03:38 PM, Mike Potanin wrote:

> The similar problem arises in a case
> let ring l = let rec r = l@r in r
> OCaml type system can not understand that the design is safe.

But it is not unconditionally safe.  Its safety depends on how
you defined the @ function.  O'Caml doesn't want to look at
the definition of @ because separate compilation is a very
important feature.

-- Damien

-------------------
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

Re: [Caml-list] let rec

[Mike Potanin]

On Sat, 18 Jan 2003, Damien Doligez wrote:

> On Thursday, January 16, 2003, at 03:38 PM, Mike Potanin wrote:
>
> > The similar problem arises in a case
> > let ring l = let rec r = l@r in r
> > OCaml type system can not understand that the design is safe.
>
> But it is not unconditionally safe.  Its safety depends on how
> you defined the @ function.  O'Caml doesn't want to look at
> the definition of @ because separate compilation is a very
> important feature.

If extend type model compiler can handle this case. The type of @ function
may content information "this function is realy lazy for second argument".
This don't handle all case recurcive data, but impotant case.
Mercury language don't handle all "modes" too :-).

>
> -- Damien

-------------------
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

Re: [Caml-list] let rec

[Vitaly Lugovsky]

On Sat, 18 Jan 2003, Damien Doligez wrote:

> > The similar problem arises in a case
> > let ring l = let rec r = l@r in r
> > OCaml type system can not understand that the design is
> > safe.
>
> But it is not unconditionally safe.  Its safety depends on how
> you defined the @ function.  O'Caml doesn't want to look at
> the definition of @ because separate compilation is a very
> important feature.

 And why not declare safety flags in the .cmi files?
It's even possible to declare side-effects existance (but, there
will be some problems with bindings).

-------------------
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