Scala Debate

A gentle reminder... deadline for submitting to the Scala Workshop is Jan 16.One free registration voucher per accepted paper!
best wishes for 2012,adriaan

On Thu, Nov 17, 2011 at 4:00 PM, Adriaan Moors <adriaan [dot] moors [at] epfl [dot] ch> wrote:

Dear Lists,

In my quest for better performance with the immutable TreeMap/TreeSet code I hit upon the following strange, but somewhat useful behavior:

$ scala -optimize
Welcome to Scala version 2.9.1.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_29).

scala> :paste
// Entering paste mode (ctrl-D to finish)

class Bar(final val a: Int, final val b: Int, final var c: Int, final var d: Int) {
def bar = a + c
}

// Exiting paste mode, now interpreting.

defined class Bar

scala> :javap -p Bar
Compiled from ""
public class Bar extends java.lang.Object implements scala.ScalaObject{
public final int a;
private final int b;
public final int c;
private final int d;
public final int a();
public final int b();
public final int c();
pu

Scalas type inference engine is not as powerful than Haskells. See the
following code snippet:

size xs = loop xs 0
where
loop [] acc = acc
loop (_ : xs) acc = loop xs (acc+1)

In Scala one have to write:

def size[A](xs: List[A]) = {
def loop(xs: List[A], acc: Int): Int = xs match {
case Nil => acc
case _ :: xs => loop(xs, acc+1)
}
loop(xs, 0)
}

This is not possible:

def size(xs) = {
def loop(xs, acc) = xs match {
case Nil => acc
case _ :: xs => loop(xs, acc+1)
}
loop(xs, 0)
}

On StackOverflow I asked some months ago why this is not possible[1].
But now I want to know if it is possible to implement such a feature.

I am working on a research prototype of safety-critical software for
air traffic control. One of my goals is to eliminate as many potential
sources of bugs as possible, both major and minor.

Passing arguments by keyword is a simple way to eliminate a whole
class of bugs. It goes beyond just checking argument types and checks
names too. Without it, if more than one argument in a list has the
same type, the compiler cannot tell if they were passed out of order.
Nor can anyone reading the source code, without referring to the
definition of the class, method, or function that the arguments are
being passed to.

For actual operational safety-critical code, I think that most if not
all arguments should be passed by keyword.

On Thu, Dec 29, 2011 at 2:11 PM, HamsterofDeath <h-star [at] gmx [dot] de> wrote:

so there is an intermediate array created which check if it is empty and
then returns Nil?

because List.apply is:

override def apply[A](xs: A*): List[A] = xs.toList

wouldn't it be better to return Nil directly?

scala> def f(s: String*) = s.getClass
f: (s: String*)java.lang.Class[_ <: String*]

scala> f()
res1: java.lang.Class[_ <: java.lang.String*] = class scala.collection.immutable.Nil$

option.toList

/** Returns a singleton list containing the $option's value
* if it is nonempty, or the empty list if the $option is empty.
*/
def toList: List[A] =
if (isEmpty) List() else List(this.get)

shouldn't it return Nil? did i find my first bug?

also, what is a "singleton list"? as far as i understand, a new list is
created every time i call toList

scalac prints a function the same way as a tuple:

scala> def f: (String, Int) => Unit = (a, b) => ()
f: (String, Int) => Unit

scala> def g: ((String, Int)) => Unit = a => ()
g: (String, Int) => Unit

This leads to incomprehensible error messages. One of them is mentioned
in this topic on StackOverflow [1].

I think either the string representation of tuples or the one of
functions should be changed.

Is there already a topic discussing this? If not, do you agree to change
the string representations?

[1] http://stackoverflow.com/questions/8610776/scala-map-foreach

On Thu, Dec 22, 2011 at 3:55 PM, Erik Osheim <erik [at] plastic-idolatry [dot] com> wrote:

1. Hardcode some fixed operators amidst the general precedence rules,
allowing things like ** to be higher priority than *, and to have the
correct associativity. This is weird, but no weirder than the hardcoded
precedence table, or the hardcoded list of unary prefix ops.