Re: [Caml-list] Are implicit modules too implicit?

[Leo White <leo@lpw25.net>]

> In this case I'm interested in if I have a block of code like the
> [print] function described in the paper knowing what possible code could
> even be executed there and how to define its definition.  For example,
> how do I go from [show 5] to the module [Show_int]?

I would expect to be able to ask merlin to automatically jump to [Show_int]
from [show 5]. I would also expect merlin to be able to produce
[show {Show_int} 5] given [show 5].
 
> In the paper, the Show implementation for an int is called Show_int and
> for list Show_list, etc.  But this is just a pleasant convention in the
> paper. 

And could easily be a pleasant convention in a library. Or possibly [Int.Show]
and [List.Show]. It's really a just a question of using sensible library design.

> What if implicit modules required specifying what module type
> they are implementing?  That would make finding instances of Show
> easier.  How this would look is in the paper:
> 
> implicit module Foo : Show = struct ... end
> 

That wouldn't work as it would make Foo.t abstract. If/when OCaml supported
transparent ascription (perhaps with :>) then you could write:

  implicit module Foo :> Show = struct ... end

which would at least be correct, but I don't really see the benefit of forcing users
to do this since the .mli file (which is where you should be looking for definitions
anyway) will already contain:

  implicit module Foo : Show with type t = ...

Of course it might contain:

  implicit module Foo : ShowAndOtherStuff with type t = ...

or even:

  implicit module Foo : sig type t = .. ... end

instead, but this is really a question of programming style, and those are best left
up to users/organisations to decide on.

> Do you have any thoughts on how you think implicit modules would effect
> understanding a large application?

The whole design of implicits is very careful to make things as explicit and
predictable as possible. The strict position that the design takes around
ambiguity (it is always an error) means that if you can see a module with the
right type in scope then that is the module being used. I do not think reasoning
about them will be difficult, but it obviously relies on people being sensible in
how they design their libraries (just like everything else in programming).
 
Regards,

Leo