[Caml-list] My wishlist: DRY modules

[Caml-list] My wishlist: DRY modules

[Brian Hurt]

I'm doing some work with modules, and I'm learning some of their 
annoyances.  Number one is having to repeat module type definitions.  For 
example, say you have a file foo.  In foo.mli, you have:

module type T = sig
	type s
	val needed : ...
end

module type S = sig
	type t
	val doit : ...
	val orelse : ...
end

module Make(Arg: T) : S with type t = Arg.s

So far, so good, but now in foo.ml you need to replicate the definitions 
of *both* T and S:

module type T = sig
	type s
	val needed : ...
end

module type S = sig
	type t
	val doit : ...
	val orelse : ...
end

module Make(Arg: T) = struct
    type t = Arg.s
    let doit = ...
    let orelse = ...
end

Now, if you know your module signatures when you start, this isn't that
big of a problem- it's a cut and paste.  Unfortunately, if you don't know
your module signatures at the begining, to add or subtract or change a
type or val you need to update the signature in *three* different places.

I wish you didn't have to repeat the module definitions in the module 
file *if* you have a .mli file.

The subject line, BTW, comes from the Pragmatic Programmer book's DRY 
principle- Don't Repeat Yourself.

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

Re: [Caml-list] My wishlist: DRY modules

[brogoff]

On Wed, 13 Oct 2004, Brian Hurt wrote:
>
> I'm doing some work with modules, and I'm learning some of their
> annoyances.  Number one is having to repeat module type definitions.  For
> example, say you have a file foo.  In foo.mli, you have:

It's annoying, but in the case you describe, just put the signatures
in their own separate file (sigs.ml or whatever), then you refer to them as
Sigs.T, Sigs.S, etc.,  and  you don't need to  repeat them, or change them in
more than one place as you develop. If you do it that way, the annoyance
becomes pretty small.

I think it would be very helpful if you could actually refer to the signature
implied by a .mli file as a signature so as to use include. People have
complained about this before, maybe we'll see it in a future OCaml.

> I wish you didn't have to repeat the module definitions in the module
> file *if* you have a .mli file.

In the case you described, I don't think you have to. If you want to extend a
module like List you need to copy the .mli, which is still an annoyance, and
violates your DRY principle.

Anyways, parameterized module systems like MLs are great.

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

Re: [Caml-list] My wishlist: DRY modules

[skaller]

On Thu, 2004-10-14 at 09:09, brogoff wrote:
> On Wed, 13 Oct 2004, Brian Hurt wrote:
> >
> > I'm doing some work with modules, and I'm learning some of their
> > annoyances.  Number one is having to repeat module type definitions.  For
> > example, say you have a file foo.  In foo.mli, you have:
> 
> It's annoying, but in the case you describe, just put the signatures
> in their own separate file (sigs.ml or whatever), then you refer to them as
> Sigs.T, Sigs.S, etc.,  and  you don't need to  repeat them, or change them in
> more than one place as you develop. If you do it that way, the annoyance
> becomes pretty small.

But can you do that with functor instances?

When I write something like:

module IntSet = Set.Make(struct type t = int end)

but type of IntSet is be spelled out long hand
in the mli file. This is far worse than merely
reflecting the interface of a module you wrote
by hand -- it also breaks with upgrades to
the library :(

Of course I can use ocamlc -i, but then I can't
apply any constraints. I'd like to be able
to instantiate a functor type too. Can this be done?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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] My wishlist: DRY modules

[Jacques Garrigue]

From: skaller <skaller@users.sourceforge.net>

> But can you do that with functor instances?
> 
> When I write something like:
> 
> module IntSet = Set.Make(struct type t = int end)
> 
> but type of IntSet is be spelled out long hand
> in the mli file. This is far worse than merely
> reflecting the interface of a module you wrote
> by hand -- it also breaks with upgrades to
> the library :(

In the interface, you just write:
  module IntSet : Set.S with elt = int

So you see that as long as you have the right signature defined
somewhere, your interfaces are going to be pretty short.

My main grudge is that an interface is not a signature, so you cannot
write things like:
  module MyList : List
while you can create an interface from a signature
  (* myList.mli *)
  include ListSig

Jacques Garrigue

-------------------
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] My wishlist: DRY modules

[Tony Edgin]

This is a reply to an old email, but it reflects something I just learned.

On Thu, 14 Oct 2004 11:00, Brian Hurt wrote:
> I'm doing some work with modules, and I'm learning some of their
> annoyances.  Number one is having to repeat module type definitions.  For
> example, say you have a file foo.  In foo.mli, you have:
>
> module type T = sig
> 	type s
> 	val needed : ...
> end
>
> module type S = sig
> 	type t
> 	val doit : ...
> 	val orelse : ...
> end
>
> module Make(Arg: T) : S with type t = Arg.s
>
> So far, so good, but now in foo.ml you need to replicate the definitions
> of *both* T and S:
>
> module type T = sig
> 	type s
> 	val needed : ...
> end
>
> module type S = sig
> 	type t
> 	val doit : ...
> 	val orelse : ...
> end
>
> module Make(Arg: T) = struct
>     type t = Arg.s
>     let doit = ...
>     let orelse = ...
> end

One partial solution would be to do the following in your foo.ml file.

module type T = Foo.T
module type S = Foo.S

module Make(Arg: T) = struct
	type t = Arg.s
	let doit = ...
	let orelse = ...
end

;;

cheers.

-- 
Tony Edgin
CARP