Scala Debate

I asked myself why Scala hasn't an exponential operator like '^' or '**'
as many other languages have.

I noticed that Scalas precedence rules will not work very well with such
operators because '^' has low precedence and '**' has the same
precedence than '*' and '/'.

Therefore I want to know if would be a good design decision to introduce
such an operator to the language (either to the libs as an implicit
conversion or as a built-in operator).

What yo you think? Do you appreciate such an operator or do you think
that there will be more problems than advantages?

On Sat, Dec 17, 2011 at 11:27 PM, martin odersky wrote:
> On Sat, Dec 17, 2011 at 11:22 PM, Miles Sabin wrote:
>> On Sat, Dec 17, 2011 at 9:07 PM, Paul Phillips wrote:
>>> scalac, I have a burning question for you:
>>>
>>> class A {
>>>  // Why can't I get my hands on "MyType", if I want to write:
>>>  //   def otherMe: MyType
>>>  // You know you can do this, scalac! I will prove it to you:
>>>  def f = this
>>> }
>>
> We have been around this so often that I do not really want to go into
> it anymore. MyType is attractive at first, but then lets you down
> badly.

I know it's come up often, but I can't find any precise statement of
what the problems are.

scalac, I have a burning question for you:

class A {
// Why can't I get my hands on "MyType", if I want to write:
// def otherMe: MyType
// You know you can do this, scalac!

On Sat, Dec 17, 2011 at 5:45 PM, martin odersky wrote:
>> No, but proguard isn't able to remove view classes in many cases even
>> if they are not used any where in user code. And they are the current
>> road block for using the Scala standard library with Android.
>
> It would be good to dig deeper on this one. Why can't proguard remove
> these classes?

I don't know.

I am apparently incapable of replying to the list directly.
Sorry Paul.

On Sat, Dec 17, 2011 at 07:27:42AM -0800, Paul Phillips wrote:
> Hey lurkers, you think this is irrelevant to you if you don't use
> views, think again. Drink in the trait signature below and, if you
> have the courage, follow the thread of interlocking type parameters
> and bounds as far as it goes. Then try to imagine what kind of tax
> that places on changing anything in the collections. Oh, you don't
> want to change anything in the collections? Can I close all the
> tickets then?

OK, I'll bite.

For the work I'm doing I have tended to stay away from views.

Speaking of things not pulling their weight: views.

Library jar before and after ripping out views.

% ls -l /scratch/trunk2/build/pack/lib/scala-library.jar
-rw-r--r-- 1 paulp admin 7161826 Dec 16 19:53
/scratch/trunk2/build/pack/lib/scala-library.jar
% ls -l /scratch/trunk3/build/pack/lib/scala-library.jar
-rw-r--r-- 1 paulp admin 6561034 Dec 16 19:51
/scratch/trunk3/build/pack/lib/scala-library.jar

Statistics from the scala code in my general ~/src directory.

% find . -name '*.scala' -print0 |xargs -0 cat | wc -l
904766
% find . -name '*.scala' -print0 |xargs -0 ack '\.view\b' |egrep
-v ':(import|package)' | grep -v deprecated |wc -l
92

One view usage per 10,000 lines of scala code.

Dear Scalarazzi,
Of those of you who use actors in your code who would feel they might benefit from the idea of a virtual mailbox? Specifically, what if 

• the idea of a mailbox were subsumed by the idea of a standing query 
• the scheduling of code to run in response to a message matching the query was -- in part -- controlled by a small range of policy constraints
• and likewise, the persistence of data associated with a message and code to be run in response to matching messages was controlled by a small range of policy constraints

To make this more concrete, would an API of the following shape be of interest or benefit?

Hello scalaists...

it's just a minor thing - but somehow I feel that all the wiring with
manifests I have to do to achieve rather mundane things like this:

class Coordinate[T <: Dimensional, P] (values: Seq[P]) (
implicit ddesc: Dimension[T], prec: Numeric[P], m: Manifest[P]
){
private var _coord = new Array[P](ddesc.dim);
...
}
def coord: Array[P] = _coord
}

could be provided by the compiler rather automatically.

Would it be possible to "enhance" the compiler to cause him to provide the
manifests required *indirectly* by a given method as an anonymous/automatic
implicit parameter?

Maybe I did something wrong but I have those Manifests (when dealing with
arrays and matches) all over the place and it feels like boilerplate.