Functions, Tuples, Sequences
Judson, Ross <rjudson <at> managedobjects.com>
2006-03-07 22:25:04 GMT
Scala unifies functions and objects via definitions for apply(), and the
FunctionN types. Consider this small extension of the basic Function2
type:
package scala;
/**
* Function with 2 parameters
*/
mixin class Function2[-T0, -T1, +R] extends AnyRef {
def apply(v0: T0, v1: T1): R;
final def apply(tuple: Tuple2[T0,T1]): R = apply(tuple._1, tuple._2);
final def apply(s1: Seq[T0], s2: Seq[T1]): Seq[R] = new Seq[R] {
def apply(n: int) = Function2.this.apply(s1(n), s2(n));
def length = s1.length;
def elements = Function2.this.apply(s1.elements, s2.elements);
}
final def apply(i1: Iterator[T0], i2: Iterator[T1]): Iterator[R] = new
Iterator[R] {
def hasNext = i1.hasNext;
def next = apply(i1.next, i2.next);
}
def apply[X](f1: X => T0, f2: X => T1): X => R = (x: X) =>
apply(f1(x),f2(x));
def apply[X,Y](f1: X => T0, f2: Y => T1): (X,Y) => R = (x: X, y: Y) =>
apply(f1(x),f2(y));
override def toString() = "<function>";
}
We've gained several things. First, we can apply the function with a
full argument list OR a tuple containing precisely the same types. This
is a convenient shorthand. Second, I have inserted additional apply
methods that recognize sequences and iterators, then perform reasonable
(?) actions. This allows me to write:
object tt extends Application {
val adder = (x: String, y: int) => Integer.parseInt(x) + y;
val times = (a: int, b: int) => a * b;
val t = Tuple2("43", 43);
Console.println(t(adder));
val listA = List("10", "11", "12");
val listB = List(1,2,3);
val listC = List(4,5,6);
for (val z <- listA.zip(listB))
Console.println(adder(z));
for (val a <- adder(listA, listB))
Console.println(a);
val mult = times(listB, listC);
Console.println(mult);
def * = (a: int, b: int) => a * b;
val m = listB * listC; <-- will not compile (and shouldn't yet)
type Time = int;
val oddSeconds = (t: Time) => (t % 2) == 1;
val square = (t: Time) => t * t;
val gate = (b: Boolean, t: Time) => if (b) t else 0;
val gateOdd = gate(oddSeconds,square);
for (val i <- Stream.range(0, 100))
Console.println(gateOdd(i));
}
Being able to shift fluidly from tuples to arguments is useful. The
sequence and iterator-based extensions allow defined functions to be
"lifted" up to sequences and iterators automatically. In other words,
for the example I've given here any binary function automatically "does
the right thing" when used with sequences.
Except that last case; deep inside the Typers nsc is checking to see if
* is a member of List, which it is not, so compilation fails. I don't
think it's possible use implicit to instruct the compiler that if:
Val Oa = Outer[InnerA] and
Val Ob = Outer[InnerB] and
Val Result: R = Outer[InnerA] op Outer[InnerB], and
InnerA op InnerB: T is defined
Then
Result = ((left: Inner, right: Outer) => left op right)(Oa, Ob)
With this we've extended the unary member function "op" into a binary
function. If extended with the additional apply() methods outlined
above, we now have a very concise way of extending arbitrary functions
to work on sequences. This is a kind of "meta-implicit" operation, where
we want to be able to specify an implicit type context in additional to
implicit typed _values_. With such a facility I might redefine List:
class List[implicit A] { ... }
When we look for a name inside List, if it is not found we search A. If
found there, the symbol may have enough meaning to be valid, or may be
refined through another implicit conversion into what is needed.
The law of unintended consequences applies of course, but somewhere in
this is a way to cleanly fold vector programming into Scala's domain.
Keeping FunctionN light is very important if any replication is
performed. But...since Scala is unifying functions and objects, doesn't
it make sense that Scala's function/objects be a little smarter than
normal "dumb" functions?
I modified FunctionN to have the extra "apply" functions. Implicit
types are obviously a deeper issue, but interesting, nonetheless. You
can also see a pair of higher-order composers above, as well...I am
still thinking through the implications of them. Composing higher order
functions is fraught with twistiness, so I thought it might be useful to
have a few common cases easily accessible.
RJ
Question #1: How in the hell does the Application trait work, and how would
I create one like it (say, for a servlet)? I can't figure out how to
replicate that behavior in a different trait, such that the body of the
class defined would be called when something in the trait is called (the way
main() in the trait somehow executes the body of the "<<thing>> with
Application" does).
Ted Neward
Author, Presenter, Consultant
Java, .NET, XML services
RSS Feed