Can Scala be seen as an 'Abstraction Inversion'?

And the very concept is a bit dubious. But the fundamental gist of it seems to be that some basic element is hidden by the abstraction, forcing users of that abstraction to re-implement it.

And the very concept is a bit dubious. But the fundamental gist of it seems to be that some basic element is hidden by the abstraction, forcing users of that abstraction to re-implement it. For instance, from the talk page, comes a much more interesting example.

Suppose a CPU had a tan math function, but no sin or cos, and a programming language implemented sin and cos in terms of tan, but did not expose tan itself. A programmer using that language would be forced to implement tan in terms of sin and cos, which, themselves, are implemented in terms of tan, therefore characterizing abstraction inversion.So, back to Scala. Naturally, a programmer using functions in Scala is not incurring in abstraction inversion, because he is not being forced to re-implement a functionality available as a primitive to Scala.

On the other hand, one might claim that Scala's implementation of functions as class instances is an instance of abstraction inversion. For that to be true, however, two things must also hold true: There must be a "function" primitive available to JVM. Such a primitive must have offered an alternative to what Scala is doing.

What, exactly, is a function? What would a function primitive look like? In this context, "function" means data that is capable of being executed.

One might say that all assembler code, is, in fact, data that is capable of being executed -- only it is not portable, and, futhermore, not bytecode, therefore failing the design principles. On the other hand, all methods in Java are referenced by an identifier, through which Java locates the code to be executed for a given object's class hierarchy. This identifier is not exposed, though it can be used indirectly through reflection.

If it were exposed, and some functionality offered to say "call this code", then a function could arguably be constructed around that.So, I think a case could be made for 1 to be true. Let's proceed to the next. If Java did offer a "method" data type, would Scala functions cease to be instances of a class?

No, they would not. One of the fundamental design aspects of Scala is that every element of a running program is an object. The "primitives" that Java already have are presented as if they were normal objects with methods, and if there was a "method" primitive, so would it.

One possible consequence of method primitives would be to elevate methods to first class citizens, but functions, themselves, would hardly change.

1 your the one! + 1000 for understanding in depth the question, giving a really good detailed answer and .. being a FreeBSD commiter! Thanks a lot, and I agree this article is pure crap... must be rewrited or deleted.

– Alois Cochard Nov 17 '10 at 6:47.

Implementing a function via an object is not done simply because that's what's possible on the JVM, it cuts right to the underlying philosophy of Scala. Everything is an object: functions, actors, number literals, etc. It's also possible for any object to be appliable (by defining the apply() method) without actually being a subclass of FunctionN. This duality is fundamental in the design of many standard library APIs, it allows for e.g. Maps to be viewed as both a function (mapping keys to values) and as a object (a collection of key/value pairs).

Scala is a true object/functional hybrid, with neither paradigm being dominant.

2 +1 for the philosophical approach :-) – Landei Nov 16 '10 at 15:32 1 I only do it for the upvotes :) – Kevin Wright Nov 16 '10 at 15:39.

No, it can't be seen as abstraction inversion. The reason is simple: In Scala you have a choice which abstraction level you prefer. Most of the time it's more convenient to write val f = 2 * (_:Int) //--> f: (Int) => Int = f(21) //--> res5: Int = 42 but it is no problem to do it the "long" way: val f = new Function1Int,Int { def apply(v:Int) = 2*v } //--> f: java.lang.

Object with (Int) => Int = f(21) //--> res6: Int = 42 As FunctionN are traits, it's possible to use mix-in inheritance, which allows you to avoid situations like the one for Functors in C++. E.g. You could "retrofit" a Java-Map as a function: class JavaMapK,V extends java.util.

HashMapK,V with Function1K,V { def apply(k:K) = get(k) } val m = new JavaMapInt, String m. Put(5,"five") m(5) //--> res8: String = five.

I believe not. The way first-class functions are implemented in Scala is just that, an implementation detail.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.