Loading ...
Sorry, an error occurred while loading the content.
 

"ocaml_beginners"::[] use of modules and functors

Expand Messages
  • Tom Hirschowitz
    I think I don t see the problem, but I d like to understand. What exactly is wrong with this? module type HANDLER = sig type t val upcall : t - unit end
    Message 1 of 5 , Apr 17, 2002
      I think I don't see the problem, but I'd like to understand.
      What exactly is wrong with this?

      module type HANDLER = sig
      type t
      val upcall : t -> unit
      end

      module Foo (Handler : HANDLER) = struct
      type t = { handler : Handler.t }
      let make handler = { handler = handler }
      let upcall self = Handler.upcall self.handler
      let downcall self = upcall self
      end

      module Bar (Handler : HANDLER) = struct
      module Foo = Foo(Handler)
      type t = { handler : Handler.t; foo : Foo.t }
      let make foo handler = { handler = handler; foo = foo }
      let upcall self = Handler.upcall self.handler
      let downcall self = Foo.downcall self.foo
      end

      bwv211mail writes:
      > I am trying to use functors to abstract out portions of my code. But
      > I quickly ran into a problem. The following gives the flavor of it:
      >
      > module type HANDLER = sig
      > type t
      > val upcall : t -> unit
      > end
      >
      > module Foo (Handler : HANDLER) = struct
      > type t = { handler : Handler.t }
      > let make handler = { handler = handler }
      > let upcall self = Handler.upcall self.handler
      > let downcall self = upcall self
      > end
      >
      > module Bar (Handler : HANDLER) = struct
      > type t = { handler : Handler.t; foo : Foo.t }
      > let make foo handler = { handler = handler; foo = foo }
      > let upcall self = Handler.upcall self.handler
      > let downcall self = Foo.downcall self.foo
      > end
      >
      > In this code, I am trying to abstract out the use of a module as the
      > HANDLER type. The idea is that you make a downcall to Bar, which
      > makes a downcall to Foo, which becomes an upcall to Foo, which becomes
      > an upcall to Bar, etc...
      >
      > The problem is that Foo.t is not defined, since Foo is a functor. I
      > need to apply that functor to a module of type HANDLER that I would
      > create within the Bar functor. Unfortunately, that handler module
      > needs type t, which can't be defined until that handler module has
      > been fed to the Foo functor... I hope you see the problem.
      >
      > Is there a way to do this with functors?
      >
      >
      >
      >
      > To unsubscribe from this group, send an email to:
      > ocaml_beginners-unsubscribe@yahoogroups.com
      >
      > The archives of the very official ocaml list (the seniors' one) can be found at http://caml.inria.fr
      >
      > Attachments are banned and you're asked to be polite, avoid flames etc. etc.
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
      >
    • bwv211mail
      In the solution you propose, the Bar().upcall function will never be called, since you have fed the Handler module that was fed to Bar() directly to Foo().
      Message 2 of 5 , Apr 18, 2002
        In the solution you propose, the Bar().upcall function will never be
        called, since you have fed the Handler module that was fed to Bar()
        directly to Foo(). What I want instead is for Bar() to create its own
        Handler module that it can feed to Foo(). The run-time call order
        should be:

        Bar(H_fed_to_Bar).downcall
        Foo(H_fed_to_Foo).downcall
        Foo(H_fed_to_Foo).upcall
        H_fed_to_Foo.upcall
        Bar(H_fed_to_Bar).upcall
        H_fed_to_Bar.upcall

        Maybe this makes the problem clearer?
      • Tom Hirschowitz
        Ok, you want two different handlers. I didn t get that. But it seems that you re in trouble because your graph looks like H_fed_to_Bar
        Message 3 of 5 , Apr 19, 2002
          Ok, you want two different handlers. I didn't get that.

          But it seems that you're in trouble because your graph looks like

          H_fed_to_Bar <----------- Bar(H_fed_to_Bar)
          ^ |
          | |
          -------------- |
          / |
          / |
          / v
          H_fed_to_Foo <----------- Foo(H_fed_to_Foo)

          Which in this case seems to mean recursive modules, at least if you
          want the code of your functions to be written in their respective modules,
          doesn't it?

          bwv211mail writes:
          > In the solution you propose, the Bar().upcall function will never be
          > called, since you have fed the Handler module that was fed to Bar()
          > directly to Foo(). What I want instead is for Bar() to create its own
          > Handler module that it can feed to Foo(). The run-time call order
          > should be:
          >
          > Bar(H_fed_to_Bar).downcall
          > Foo(H_fed_to_Foo).downcall
          > Foo(H_fed_to_Foo).upcall
          > H_fed_to_Foo.upcall
          > Bar(H_fed_to_Bar).upcall
          > H_fed_to_Bar.upcall
          >
          > Maybe this makes the problem clearer?
          >
          >
          >
          >
          > To unsubscribe from this group, send an email to:
          > ocaml_beginners-unsubscribe@yahoogroups.com
          >
          > The archives of the very official ocaml list (the seniors' one) can be found at http://caml.inria.fr
          >
          > Attachments are banned and you're asked to be polite, avoid flames etc. etc.
          >
          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          >
          >
          >
        • bwv211mail
          ... Yes, I have convinced myself now that my current approach means recursive modules, so I am trying to architect something else. It is a good learning
          Message 4 of 5 , Apr 19, 2002
            > Which in this case seems to mean recursive modules, at least if you
            > want the code of your functions to be written in their respective
            > modules, doesn't it?

            Yes, I have convinced myself now that my current approach means recursive modules, so I am trying to architect something else. It is a good learning experience.
          Your message has been successfully submitted and would be delivered to recipients shortly.