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

Re: "ocaml_beginners"::[] Records

Expand Messages
  • Jeffrey J. Cook
    Aside from using variants/classes/etc, the best solution I can think of is to use accessor functions for your field arguments: # type a = { b : int };; type a
    Message 1 of 7 , May 31, 2004
      Aside from using variants/classes/etc, the best solution I can think of is
      to use accessor functions for your field arguments:

      # type a = { b : int };;
      type a = { b : int; }
      # let get_a_b x = x.b;;
      val get_a_b : a -> int = <fun>
      # type c = { b : int };;
      type c = { b : int; }
      # let get_c_b x = x.b;;
      val get_c_b : c -> int = <fun>
      # let f x = (get_a_b x) = 0;;
      val f : a -> bool = <fun>
      # let g x = (get_c_b x) = 0;;
      val g : c -> bool = <fun>

      It is a shame that OCaml doesn't allow your solution when the type is
      specified; I don't know any specifics about the OCaml type inference engine,
      but in some unification implementations, the function is often type inferred
      then the type annotations are checked for consistency instead of immediately
      providing a unification equation with the type annotation. I'm sure there
      are reasons to do it this way, but that's an ask the expert.

      --
      Jeffrey J. Cook
      Graduate Student, Electrical Engineering
      University of Illinois at Urbana-Champaign
      jjcook@...
    • Virgile Prevosto
      Le lundi 31 mai, à 21h30 -0500, ... What s wrong with the previously mentionned module encapsulation ? # module A = struct type a = {b:int} end;; module A :
      Message 2 of 7 , Jun 1, 2004
        Le lundi 31 mai, à 21h30 -0500,
        Jeffrey J. Cook a écrit:

        > Aside from using variants/classes/etc, the best solution I can think
        > of is to use accessor functions for your field arguments:

        What's wrong with the previously mentionned module encapsulation ?

        # module A = struct type a = {b:int} end;;
        module A : sig type a = { b : int; } end
        # module B = struct type b = { b:string} end;;
        module B : sig type b = { b : string; } end
        # let f x = x.A.b;;
        val f : A.a -> int = <fun>
        # let g x = x.B.b;;
        val g : B.b -> string = <fun>

        If you don't want to systematically use prefixed field names, you can
        use the 'open' directive (note that this will only work for one type
        at a time, but the other one can still be accessed through the fully
        qualified name). You can of course use several open directives in the
        same session:

        # open A;; (* x.b refers to the a type*)
        # let f x = x.b;;
        val f : A.a -> int = <fun>
        # open B;; (* now switch to b type *)
        # let g x = x.b;;
        val g : B.b -> string = <fun>
        # open A;; (* let's go to a again *)
        # let f x = x.b;;
        val f : A.a -> int = <fun>


        --
        E tutto per oggi, a la prossima volta
        Virgile
      • Jeffrey J. Cook
        ... Module encapsulation is what generally should be used; I was just providing ideas for temporary hack alternatives that can be sufficient for cases that
        Message 3 of 7 , Jun 1, 2004
          On Tue, Jun 01, 2004 at 11:14:10AM +0200, Virgile Prevosto wrote:
          > What's wrong with the previously mentionned module encapsulation ?

          Module encapsulation is what generally should be used; I was just providing
          ideas for temporary 'hack' alternatives that can be sufficient for cases that
          can arise well into a large project.

          --
          Jeffrey J. Cook
          Graduate Student, Electrical Engineering
          University of Illinois at Urbana-Champaign
          jjcook@...
        Your message has been successfully submitted and would be delivered to recipients shortly.