After playing around with implied instances and reading all docs, I’m intrigued about this approach. I don’t have anything to add semantic wise at this point, I like its current principles. But, given that this change is mostly about syntax, I think it might be useful to mention I struggle to get used to the implied
syntax.
Isn’t there a better keyword we could use to refer to the same concept? Possibly a keyword that bears no indirect relationship with implicit
and that doesn’t read as an adjective?
The one that comes to mind is infer
. Given that implicits is a way to infer terms, it seems appropriate to use that word instead and it being a verb means it reads like I’m telling the computer to do something.
Here’s how the code snippet in Implied Instances would look like with it:
trait Ord[T] {
def compare(x: T, y: T): Int
def (x: T) < (y: T) = compare(x, y) < 0
def (x: T) > (y: T) = compare(x, y) > 0
}
infer IntOrd for Ord[Int] {
def compare(x: Int, y: Int) =
if (x < y) -1 else if (x > y) +1 else 0
}
infer ListOrd[T] given (ord: Ord[T]) for Ord[List[T]] {
def compare(xs: List[T], ys: List[T]): Int = (xs, ys) match {
case (Nil, Nil) => 0
case (Nil, _) => -1
case (_, Nil) => +1
case (x :: xs1, y :: ys1) =>
val fst = ord.compare(x, y)
if (fst != 0) fst else xs1.compareTo(ys1)
}
}
Advantages of using infer
over implied
:
- It’s a verb and it’s similar to
def
both syntax wise (it comes from the verbdefine
) and semantics-wise (it defines an inferred term without looking like a straight value definition). - It’s two characters shorter.
- it reads nicely followed by
for
andgiven
.
Disadvantages
- It’s not clear what we should use to import an inferrable instance. I prefer either
infer import
orimport infer
but we could also go forimport inferred
. If you don’t like either, we can probably find another variation that fits the bill.
EDIT: I’ve just seen @Odomontois already proposed the same thing in passing but no one seems to have given feedback on the suggestion.