This topic provides some explanation about how implicit parameters are resulted. There are very strict rules for which implicit value is to be applied to a implicit parameter. A simple way to think about it is that the “closest” definition will be used. Local scope, enclosing class, parent class, companion object of the desired type.

I’ll show you an English verb conjugator. Although handling inflections is complex, the structure of the language can be expressed idiomatically, using a monad. You’ll see that things like “perfect continuous” are really “perfect” on top of “continuous”, in code.

First, some boring code and auxiliary functions.

> data Tense = Past | Present | Future> type Infinitive = String> data Person = First | Second | Third> -- plural in English is the same form as second person

Evidently the topic of implicit parameters has not yet been correctly addressed. There have been several topic that refer to implicit parameters but none that directly discuss them. So before I continue with the topic of implicit parameter resolution I will discuss implicit parameters.

First, implicit parameters are not the same as implicit object conversions. Implicit parameters provide a way to allow parameters of a method to be “found”. This is similar to default parameters at a glance but in fact is a different mechanism for finding the “default” value. It differs from implicit object conversion in that it is only a way for parameters for a method to be resolved. Implicit object conversion allows methods to appear to be called on one object when in fact that object is being converted behind the scenes to another type. (more or less)

An implicit parameter is a parameter to method or constructor that is marked as implicit. This means that if a parameter value is not supplied then the compiler will search for an “implicit” value defined within scope (according to resolution rules.) Implicit parameter resolution rules will be discussed soon.

Example:

scala>def p(implicit i:Int) = print(i)

p: (implicit i: Int)Unit

// defining a val/var/def as implicit

// means that it will be considered during implicit resolution

scala> implicit val v=2

v: Int = 2

// scope is searched for a implicit value to sue

// v is found as marked implicit

scala> p

2

// explicit declarations always overrides implicit values

scala> p(1)

1

Implicit parameters are very nice for simplifying APIs. For example the collections use implicit parameters to supply CanBuildFrom objects for many of the collection methods. This is because normally the user does not need to be concerned with those parameters. Another example is supplying an encoding to an IO library so the encoding is defined once (perhaps in a package object) and all methods can use the same encoding without having to define it for every method call.

One important restriction is that there can only be a single implicit keyword per method. It must be at the start of a parameter list (which also makes all values of that parameter list be implicit). I further understand that only the last parameter list may be implicit.

hanging out in the old hometown of stockton… yesterday we went to one of the greatest mexican restaurants in the world… el novillero in sacramento. many a meal was consumed here in the early pavement days! we’re off to dublin in a few days to start… Continua a leggere →

In the Breaks comments there were several questions about the performance of the Scala break command vs the Java break command. So I decided to take a look.

The code for the tests is available on GitHub at: Scala Benchmarks. Feel free to play around with it.

I personally don’t think these tests say anything of particular import because they only test how fast the Java break is vs the Scala break without doing any work in the loop. So I don’t expect these number would ever been seen in the real world. However that said if you have a tight loop with minimal processing then a Scala break may not be the correct construct to use.

Here is the Java test (labelled JavaSimpleBreak)

int i = 0;

while (i < 10) {

if(i==1) break;

i += 1;

}

Here is the Scala test (labelled ScalaSimpleBreak)

var i = 0;

breakable {

while (i < 10) {

if(i==1) break;

i += 1;

}

}

Out of curiosity I also added a test that created a new Exception each iteration (labelled ScalaException):

var i = 0;

while (i < 10) {

if(i==1) thrownew Exception();

i += 1;

}

And also a test that just throws the same ScalaBreak exception each time. This one is weird since Scala Simple Break also throws the same exception but is much much faster so I think there is something about popping the stack in the example compared to the ScalaSimpleBreak test.

var i = 0;

breakable {

while (i < 10) {

if(i==1) break;

i += 1;

}

}

The results of the tests:

First, don’t compare the break tests to the Exception tests. They are sufficiently different to not be worth comparing.Second, remember that this is a micro benchmark and has very little relationship to reality.

When a method requires an implicit there are several ways that the implicit is resolved. One way is to search for an implicit definition in the companion object of the required type. For example: def x(implicit m:MyClass) parameter m will search local scope, class hierarchy and the MyClass companion object for an implicit val or def. (More on implicit resolution later).

To demonstrate the method put the following code block into a file and run the script:

ok. we conquered coachella. now the anxiety can cease. hope all who saw us enjoyed. we know we did. all in all, it was a fun show. we were a little nervous when we went on, but after a few songs we hit our stride. the response from the crowd was very g… Continua a leggere →

this is my breakfast on our united airlines flight from tokyo to los angeles… inedible! and you wonder why this airline goes bankrupt.and this is jeremy lemos travel/tour blog for the chicago reader. jeremy does killa monitors for us and is a slick d… Continua a leggere →

Scala 2.8 added the break control flow option. It is not implemented as a special language feature. Rather it is simply implemented as an object/trait using standard Scala mechanisms. If you are interested in creating a control flow object similar to this look at the Defining Custom Control Structures post.

The Break functionality is works basically how you would expect:

// Import the control flow methodsmethods

scala>import util.control.Breaks._

import util.control.Breaks._

// pass a function to the breakable method

scala> breakable {

| for (i <- 1 to 10 ) {

| if(i > 5) break // call break when done

| println(i)

| }

| }

1

2

3

4

5

Pretty intuitive but beware, break only breaks out to the first enclosing breakable. Here is an example of the issue:

scala>def loop(f : Int => Boolean) = breakable {

| for (i <- 1 to 300) if (f(i)) break else println(i)

| }

loop: (f: (Int) => Boolean)Unit

// This never ends because break is caught by breakable in the loop method

scala> breakable {

| while(true) {

| loop{ i => break; true }

| }

| }

Fortunately the implementers provide an elegant way to handle these sorts of cases. The Breaks object extends the Breaks class. By instantiating other instances of Breaks it is possible to control which breaks capture