Has anyone looked at modular implicits much? I just looked at the paper and I’m not much of a type theorist, but one concern I had reading it was it seems difficult to take something like show foo and determine what code is actually being executed. With typeclasses in Haskell, one at least has to specify that something is an instance, and you can grep for those to soem degree.
With typeclasses in Haskell, one at least has to specify that something is an instance, and you can grep for those to soem degree.
Modular implicits as proposed also have this expliciteness: there is a separate “implicit environment” in which elaboration is performed, which is explicit populated by using implicit module.
Given that implicit elaboration is exactly the construction of a term, there is an easy user-interface to tell the user which code is being elaborated: just show the term. We already have editor support for “what is the type of this term”, it’s easy to extend this with “what is the implicit argument of this call” and I think it solves the problem of understanding of written code.
The design problem that remains is: what are the right primitives to manipulate the implicit environment in a way that is expressive enough, preserves non-ambiguity of resolution, and makes it easy for users to predict what elaboration choices will be made? We’ll get a taste of this as we continue experimenting with implicits.
I don’t know anything about modular implicits, but I’ve seen people raise similar concerns about scala implicits. In practice I find it’s very much not a problem as long as you’re willing to embrace tooling - your IDE knows exactly what code is being called and can show you at the right level of shoutiness (there’s no reason e.g. IntelliJ couldn’t always “unfold” implicits if you wanted that, in the same way that it “folds” anonymous functions in Java 7).
Where it can be a problem is things like code review tools where you only have the text of the code - but in a code review situation you usually just want to confirm that the code is readable and adequately tested, and hiding away the typeclass implementation if anything helps with that - the situation where you need to know exactly what code is executing is debugging, which you would almost always do in an IDE.
and hiding away the typeclass implementation if anything helps with that - the situation where you need to know exactly what code is executing is debugging, which you would almost always do in an IDE.
I’m not sure if you mean this only in the case when you have something like a typeclass or if you mean this in general, but in general I think one should strive hard to avoid the situation where they do not know what code is being executed just by reading it. I’m mostly on the fence about this implicit module stuff because It seems very powerful without much restrictions to keep usages sane.
I normally scoff when people talk about moving code beyond plain text, but I’ve found (scala) implicits with IDE support to be a case where there is real value in doing so: for concerns that are too important to be completely invisible when reading, but not important enough to be in the text, having them visible as just an underline/icon that can be expanded is a fantastic compromise. Naïvely one might think it would result in just giving the reader less information than in a language where that simply wasn’t an option, but in practice the big use case is effect tracking that you simply wouldn’t do if doing so were more verbose. It’s certainly a feature that’s easy to misuse and I would probably want to restrict use to typeclass-like cases (in which case what code is being run is not really any more hidden than it is for a polymorphic OO method call - which function is called is completely determined by the static type of the argument) and Spray’s “magnet pattern”, but I wouldn’t want to go back to not having it.
Months ago, (there was a mention that 4.03 would include multicore)[https://sympa.inria.fr/sympa/arc/caml-list/2015-05/msg00034.html], if all goes well. Since it’s not mentioned, I’m guessing it didn’t quite go well enough.
Anyone know what the status is looking like?
It looks like it was briefly mentioned at the end in “whats missing” (assuming that the author didn’t just recently edit the linked article to add that section)
multicore GC, which at one point had been expected to land in 4.03, has been pushed back, likely to 4.04.
At the time it was clear already that Damien was extremely optimistic in this remark. To my knowledge, nothing “went wrong” with the multicore project, it’s just that it requires a terrific amount of work. The work on effect-handlers as a user-interface is promising, and the work on getting native compilation to work with the multi-core runtime has been progressing well.
My reaction as I read this (as a Haskell weenie):