Scala Debate

h1 { font-family: "Times New Roman", serif; font-size: 16pt; margin: 12pt 0; page-break-after: avoid; }
h2 { font-family: "Times New Roman", serif; font-size: 14pt; margin: 10pt 0; page-break-after: avoid; }
p { font-family: "Times New Roman", serif; font-size: 11pt; margin: 0; text-indent: .2in; }
pre { font-family: Consolas, monospace; font-size: 10pt; margin: 0; }
code { font-family: Consolas, monospace; font-size: 10pt; }
.BlockQuote { margin: 6pt 0; text-indent: .4in; }
.CodeBlock { margin: 11pt 0 11pt .15in; }
.Hanging { margin: 0 0 6pt .33in; text-indent: -.33in; }
.NoI

When I first started trying to learn Scala a few years ago there was so
much hype in the documentation about how wonderful pattern matching was,
but I didn't really pay much attention to it as I could not get a feel
for the utility of it.

Now that I have been writing more product code in Scala, increasingly I
find myself using match/case so much now that I am getting addicted to
it.

(returning to scala-debate after accidentally straying off-list)

On Tue, Jan 31, 2012 at 2:49 AM, Erik Osheim wrote:
> On Tue, Jan 31, 2012 at 12:15:34AM +1100, Ben Hutchison wrote:
>> While it's possible to use the same typeclass twice in a method for
>> different types, I think its uncommon. I've not encountered code like
>> your example - why do you bring 2 numerics of unrelated type together
>> and want to operate on both?

> In the case I'm talking about there'd be conflicts around things like
> Numeric[A].fromInt(i:Int):A versus Numeric[B].fromInt(i:Int):B as well
> as Numeric[A].zero:A versus Numeric[B].zero:B. In fact, I have existing
> code that would be affected by this feature.

I've been thinking about submitting a new SIP, but I want to get a sanity check and some help first...  I would like to be able to memoize the results of referentially transparent functions / methods.  I can do this manually by implementing some caching strategy encapsulated in, say, a MemoizedFunction[-T, +R]...  But that feels unsatisfying; I want language support.

Since I know nobody could possibly be tired of this subject, and also
I didn't know what else to do with my test case.

class A { def f: Any }
class B extends A { def f: Int = 5 }
class C extends A { def f: Long = 5L }

object Test {
def hello[T: Ordering](t1: T, t2: T) = ???

implicit val AOrdering: Ordering[A] = ???

hello(new B, new C)
// ./a.scala:11: error: No implicit Ordering defined for A{def f: AnyVal}.
// hello(new B, new C)
// ^

hello(new B, new C)(AOrdering)
// ./a.scala:13: error: type mismatch;
// found : Ordering[A]
// required: Ordering[A{def f: AnyVal}]
// Note: A >: A{def f: AnyVal}, but trait Ordering is invariant in type T.
// You may wish to investigate a wildcard type such as `_ >: A{def
f: AnyVal}`.

Hi,

Actors can be used to break tasks down into smaller chunks and process
them on multiple cores, or even multiple machines via remote actors.
Additionally, they can wrap mutable data, so you don't need to write
your own locking mechanisms on such data.

MapReduce in systems like Apache Hadoop break tasks down into smaller
chunks and process them on multiple cores, on multiple servers, but
have the benefit over actors that they work with distributed file
systems and databases, so out of the box you have persistence. So far
as I know, Hadoop does not help with locking on mutable data.

Java EE application servers don't break work down into little tasks,
rather each single request (through say a call to a web service being
hosted on the app server) is a "little" task.

Is this email not displaying properly?
View it in your browser.

Dear Google user,