forward function definitions

forward function definitions

[Junbiao Zhang]

Hi,

	We're developing a fairly large system with multiple function
definitions. It's inevitable that some functions may call other functions
defined later(may not even be recursive calls as in the case of
Sys.Signal_handle). My question is: how do I solve such a problem which is
extremely trival in other languages?  Thanks. 

--Junbiao

My current solution is really ugly: 

let a_forward_ref = 
  (ref (fun _ -> raise (Failure "undefined") : int -> unit));;


let register_signals () = 
  .....
  Sys.signal Sys.sigalrm (Sys.Signal_handle !a_forward_ref)
  .....

.........

let a sigid = 
  ......

let assign_a_forward_ref () = 
  a_forward_ref := ref a	

And im main()(may be in another file):

  ......
  assign_a_forward_ref ()
  ......


I must be missing something or this language is:)

Re: forward function definitions

[Sven LUTHER]

On Wed, Jun 09, 1999 at 02:38:22PM -0400, Junbiao Zhang wrote:
> Hi,
> 
> 	We're developing a fairly large system with multiple function
> definitions. It's inevitable that some functions may call other functions
> defined later(may not even be recursive calls as in the case of
> Sys.Signal_handle). My question is: how do I solve such a problem which is
> extremely trival in other languages?  Thanks. 

If the two functions are in different modules, just provide a interface file
for them, and it should work ok but can cause some linker problems.

2 clean way of doing this are :

* use the later called function as a parameter to the first called function :

  let register_signals_arg f =  Sys.signal Sys.sigalrm (Sys.Signal_handle f)

  ...
  
  let a sigid = ...
  let register_signals = register_signals_arg a
  
* Or you could define all this in the form of a module functor :

  module type XXX = sig val a : id -> ... end
  module Make_M (X : XXX) = struct
    let register_signals =  Sys.signal Sys.sigalrm (Sys.Signal_handle X.a)
	 end
  module ARG = struct 
    let a sigid = ...
	 end
  module M = Make_M ARG
  open M
	
Friendly,

Sven LUTHER

Re: forward function definitions

[Pierre Weis]

> On Wed, Jun 09, 1999 at 02:38:22PM -0400, Junbiao Zhang wrote:
> > Hi,
> > 
> > 	We're developing a fairly large system with multiple function
> > definitions. It's inevitable that some functions may call other functions
> > defined later(may not even be recursive calls as in the case of
> > Sys.Signal_handle). My question is: how do I solve such a problem which is
> > extremely trival in other languages?  Thanks. 
> 
> If the two functions are in different modules, just provide a interface file
> for them, and it should work ok but can cause some linker problems.
> 
> 2 clean way of doing this are :
> 
> * use the later called function as a parameter to the first called function :

That's a neat solution, although this trick works only when the
``later defined'' function is monomorphic, or at least is not
polymorphically called (the same problem arises with the reference
trick). Furthermore, this extra argument is a bit confusing, since, as
a forward, it should always be exactly the same value and nothing
helps the reader to understand this. Furthermore, the compiler has no
ways to warranty this semantics.

> * Or you could define all this in the form of a module functor :

In this case, you can polymorphically use a forward definition,
although is appears to me to be really a heavy loaded syntactic way of
defining forwards...

Friendly,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/

Re: forward function definitions

[luther sven]

On Mon, Jun 14, 1999 at 06:17:22PM +0200, Pierre Weis wrote:
> > On Wed, Jun 09, 1999 at 02:38:22PM -0400, Junbiao Zhang wrote:
> > > Hi,
> > > 
> > > 	We're developing a fairly large system with multiple function
> > > definitions. It's inevitable that some functions may call other functions
> > > defined later(may not even be recursive calls as in the case of
> > > Sys.Signal_handle). My question is: how do I solve such a problem which is
> > > extremely trival in other languages?  Thanks. 
> > 
> > If the two functions are in different modules, just provide a interface file
> > for them, and it should work ok but can cause some linker problems.
> > 
> > 2 clean way of doing this are :
> > 
> > * use the later called function as a parameter to the first called function :
> 
> That's a neat solution, although this trick works only when the
> ``later defined'' function is monomorphic, or at least is not
> polymorphically called (the same problem arises with the reference
> trick). Furthermore, this extra argument is a bit confusing, since, as
> a forward, it should always be exactly the same value and nothing
> helps the reader to understand this. Furthermore, the compiler has no
> ways to warranty this semantics.

Ah, but you can define a wrapper immediately following the definition of the forwarder function :

let f for () = ...

...

let for ... = ...
let true_f = f for

Friendly,

Sven LUTHER

Re: forward function definitions

[Pierre Weis]

> Ah, but you can define a wrapper immediately following the definition of the forwarder function :
> 
> let f for () = ...
> 
> ...
> 
> let for ... = ...
> let true_f = f for
> 
> Friendly,
> 
> Sven LUTHER

Yes you can do so, but you once again get the same polymorphism
problem:
1) If for is used polymorphically in the body of f you're dead.
2) true_f will be monomorphic as well, unless you eta-expand it as in:
   let true_f () = f for ()

PS: for is indeed a keyword, and this identifier cannot be used as a
regular argument or function name ...

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/

Re: forward function definitions

[Sven LUTHER]

On Wed, Jun 16, 1999 at 10:55:31PM +0200, Pierre Weis wrote:
> > Ah, but you can define a wrapper immediately following the definition of the forwarder function :
> > 
> > let f for () = ...
> > 
> > ...
> > 
> > let for ... = ...
> > let true_f = f for
> > 
> > Friendly,
> > 
> > Sven LUTHER
> 
> Yes you can do so, but you once again get the same polymorphism
> problem:
> 1) If for is used polymorphically in the body of f you're dead.
> 2) true_f will be monomorphic as well, unless you eta-expand it as in:
>    let true_f () = f for ()
	 
Ok, true, but it solves the lisibility problem.

I have a similar problem :

i am intenting to write a little function, using the mlgtk gtk+ bindings, that
will popup a dialog window and ask the user for a string. The dialog window
will activate a callback when i type enter in the entry widget.

here is what i plan to do :

let todo = ref None

let activate entrywidget =
  let s = (* stuff to get the string in the entry widget *)
  in match !todo with
    | None -> raise Error
	 | Some f -> f s

let get_string f = match !todo with
  | Some f' -> ()
  | None ->
    let () = todo := Some f
	 in (* stuff to open the dialog box,
        * and connect the activate handler to it
        *)

is this the best way to do things like that, what other possibilities are there
?

Friendly,

Sven LUTHER

Re: forward function definitions

[Toby Moth]

> From Pierre.Weis@inria.fr Sat Jun 12 00:13:57 1999
> Date: Wed, 9 Jun 1999 14:38:22 -0400 (EDT)
> From: Junbiao Zhang <junzhang@ccrl.nj.nec.com>
> X-Sender: junzhang@flame
> To: caml-list@inria.fr
> Subject: forward function definitions
> MIME-Version: 1.0
> Sender: Pierre.Weis@inria.fr
> 
> Hi,
> 
> 	We're developing a fairly large system with multiple function
> definitions. It's inevitable that some functions may call other functions
> defined later(may not even be recursive calls as in the case of
> Sys.Signal_handle). My question is: how do I solve such a problem which is
> extremely trival in other languages?  Thanks. 
> 

Can't you just wrap up your deferred functions inside a mutable array or
an object ?

e.g. 

type 'a defer = { mutable exec : 'a }

let defer_fun = { exec = fun i -> print_int i }

let eval = defer_fun.exec;;

eval 3;;
defer_fun.exec <- fun i -> print_int ( i * 2 );;
eval 3;;

etc.
or

class defer = 
  object
    val mutable exec = fun i -> print_int i
    method update new_fun = exec <- new_fun
    method exec = exec
  end

....

I picked types here that match the types used in your example.

t