[Caml-list] Are implicit modules too implicit?

[Caml-list] Are implicit modules too implicit?

[Malcolm Matalka]

Hello,

I would like to preface this with saying that I'm not a type theorist
nor do I understand implicit modules in their totality, my question is
really about software engineering.

I have read a good chunk of http://arxiv.org/pdf/1512.01895.pdf which is
linked to from Yaron's blog post on 4.03.

The concern I have reading it that it seems difficult to, without
exposing some resolution code from the compiler, determine which
implementation of an implicit module is being executed.  An implicit
module doesn't even have to specific which module type it is
implementing.  To me, this means going from a call-site, to the actual
implementation is very difficult especially since I cannot even do some
sort of grep to find all those things that implement an implicit module
type.

Is the outline of that paper still true?  Are my concerns justified or
addressed in planned released version?  Or am I missing something and my
concerns are unjustified?

Thanks,
/Malcolm

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

[Leo White]

> To me, this means going from a call-site, to the actual
> implementation is very difficult especially since I cannot even do some
> sort of grep to find all those things that implement an implicit module
> type.

The best way of finding a variable's definition is to use merlin to jump to definition.
The same will be true for implicit call sites.

Depending on how libraries are designed I would not expect it to be difficult to locate
the instances by hand. They are managed with the same scoping mechanisms as
ordinary values, and since they should rarely be used by name they can also be
given nice descriptive searchable names.

Regards,

Leo

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

[Malcolm Matalka]

Leo White <leo@lpw25.net> writes:

>> To me, this means going from a call-site, to the actual
>> implementation is very difficult especially since I cannot even do some
>> sort of grep to find all those things that implement an implicit module
>> type.
>
> The best way of finding a variable's definition is to use merlin to jump to definition.
> The same will be true for implicit call sites.

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

>
> Depending on how libraries are designed I would not expect it to be difficult to locate
> the instances by hand. They are managed with the same scoping mechanisms as
> ordinary values, and since they should rarely be used by name they can also be
> given nice descriptive searchable names.

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

Certainly this isn't needed for correctness, but it seems nicer than
hoping people name their instances something sensible.

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

>
> Regards,
>
> Leo

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

[Yaron Minsky]

I think the library design issues with implicits are still quite open.
Our intent with Core is to step pretty gradually into this area.  I
expect that some things like sexp-conversion will be moved to
implicits pretty eagerly, but that we'll be quite cautious for a
while.

It's worth noting that modules must in this proposal be marked
explicitly to be available for implicit selection.  So you can grep
for implicit modules to some degree at least.

My guess is that with respect to Core, we'll end up in a state where
implicits are used in a quite limited manner.  I think they'll be
quite useful, but I don't expect to have many kinds of implicits
floating around in the scope by default.

y

On Wed, Mar 2, 2016 at 8:59 AM, Malcolm Matalka <mmatalka@gmail.com> wrote:
> Leo White <leo@lpw25.net> writes:
>
>>> To me, this means going from a call-site, to the actual
>>> implementation is very difficult especially since I cannot even do some
>>> sort of grep to find all those things that implement an implicit module
>>> type.
>>
>> The best way of finding a variable's definition is to use merlin to jump to definition.
>> The same will be true for implicit call sites.
>
> 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]?
>
>>
>> Depending on how libraries are designed I would not expect it to be difficult to locate
>> the instances by hand. They are managed with the same scoping mechanisms as
>> ordinary values, and since they should rarely be used by name they can also be
>> given nice descriptive searchable names.
>
> 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.  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
>
> Certainly this isn't needed for correctness, but it seems nicer than
> hoping people name their instances something sensible.
>
> Do you have any thoughts on how you think implicit modules would effect
> understanding a large application?
>
>>
>> Regards,
>>
>> Leo
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

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

[Leo White]

> 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

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

[Malcolm Matalka]

Leo White <leo@lpw25.net> writes:


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

I'm just a bit concerned about relying on convention for such a powerful
feature.


FWIW, I don't use merlin, although maybe I'll start.  One of the
strengths of Ocaml, IMO, is how much information is local to the
call-site and implicits seem to allow spooky action at a distance which
makes me a bit uneasy.

Perhaps I'm overreacting.

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

[Gabriel Scherer]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

The fact that implicits (in Scala or in this proposal) are understood as a
term elaboration problem guarantees that there is a nice user
representation to understand what is happening: just show the elaborated
term. The question of which interface is used to query this representation
is important, but I wouldn't be too worried about it. As Leo said, Merlin
should do it fine.
For compiler messages, given that there is a syntax for explicitly passing
an implicit (foo {Bar}), I would expect passing an obviously-incorrect
implicit (say foo {List}) to print an error message mentioning the correct
elaborated implicit, just as we sometimes use the ( : unit) annotation to
force the compiler to spit out its inferred type.

On Wed, Mar 2, 2016 at 10:57 AM, Malcolm Matalka <mmatalka@gmail.com> wrote:

> Leo White <leo@lpw25.net> writes:
>
>
> >> 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.
>
> I'm just a bit concerned about relying on convention for such a powerful
> feature.
>
>
> FWIW, I don't use merlin, although maybe I'll start.  One of the
> strengths of Ocaml, IMO, is how much information is local to the
> call-site and implicits seem to allow spooky action at a distance which
> makes me a bit uneasy.
>
> Perhaps I'm overreacting.
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 2596 bytes --]

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

[Gerd Stolpmann]

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

Currently I'm in a Scala project where there are a number of implicits,
and the question which implicit is actually used is a real one. Having
support in Merlin is good, but I think there could also be support in
the compiler. What about adding a warning "implicit X is resolved
as ..." which can be used for tracing the resolution during the build?

Gerd

Am Mittwoch, den 02.03.2016, 08:37 -0500 schrieb Leo White:
> > To me, this means going from a call-site, to the actual
> > implementation is very difficult especially since I cannot even do some
> > sort of grep to find all those things that implement an implicit module
> > type.
> 
> The best way of finding a variable's definition is to use merlin to jump to definition.
> The same will be true for implicit call sites.
> 
> Depending on how libraries are designed I would not expect it to be difficult to locate
> the instances by hand. They are managed with the same scoping mechanisms as
> ordinary values, and since they should rarely be used by name they can also be
> given nice descriptive searchable names.
> 
> Regards,
> 
> Leo
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Leo White]

> Currently I'm in a Scala project where there are a number of implicits,
> and the question which implicit is actually used is a real one.

It is worth bearing in mind that the resolution of implicits in Scala is much more
complicated than the rules for modular implicits. Scala has very complex scoping
rules for implicits, whereas modular implicits just uses lexical scope. Scala also
allows ambiguous implicits to be resolved according to a complex set of overloading
rules, whereas modular implicits always gives an error for ambiguous implicits.

> Having
> support in Merlin is good, but I think there could also be support in
> the compiler. What about adding a warning "implicit X is resolved
> as ..." which can be used for tracing the resolution during the build?

I suspect a warning would be a bit too noisy to read usefully, but it should be
quite easy to have the compiler print the source of the program with all the implicit
parameters passed explicitly (so [show 5] would become [show {Show_int} 5]). It
wouldn't be able to keep the indentation of the source, but it should still be easy
to find the implicit you're interested in.

Regards,

Leo