gmane.comp.lang.scala

a function is a partial function, not vice versa

Vlad Patryshev — 2013-06-18T14:30:23

Hi,

This sounds like a very simple thing... and there might be reasons for
doing it the way it is now, but anyway.

A partial function in the library is defined as a special case of a
function.
This is wrong, I think. A function is a case of partial function (the one
that happens to have the whole type as a domain).

Do I need to prove it, or is it already obvious?

Thanks,
-Vlad

secondary constructors in case classes

Radim Kolar — 2013-06-14T09:53:12

whats rationale behind not creating additional factory methods in the 
class's companion?

Would Scala benefit from allowing partial sealing of classes

Rich Oliver — 2013-06-13T12:01:00

At the moment a class can be sealed or not sealed. Would it be useful to be 
able to partially seal a class, where partially sealing means no additional 
fields? Could a lot of currently sealed classes notably the collection 
classes, but also such classes as either and Option then be left partially 
sealed. Could we then get rid of a lot of implicits that have such 
horrendous effects on compile times? Allowing classes such as 

class FooList extends List[Foo] { ...... }

the craze that's sweeping scala town

Paul Phillips — 2013-06-13T02:08:14

Maybe after all these years I'm getting used to the fact that whatever it
is, someone will have the time and energy to mount a campaign against it.
Have at it.

% cat a.scala
def program(args: Array[String]) {
  println(s"""
    |Thank you for participating in "Top Level Method", the craze that's
sweeping
    |scala town. Your arguments were: ${args mkString " "}
    |""".stripMargin.trim
  )
}
% qscalac a.scala
% qscala program bippy boo
Thank you for participating in "Top Level Method", the craze that's sweeping
scala town. Your arguments were: bippy boo
%

fun with union types

Paul Phillips — 2013-06-12T08:47:07

https://gist.github.com/paulp/5763757

class Cell[T](value: T) {  var other: T = value}object Test {  def
g[T, U](x: T, y: U) = if (util.Random.nextBoolean) x else y  def f1 =
g(1f, "abc")  def f2 = g(1: Byte, "abc")  def f3 = g(f1, f2)  /***
Inferred return types:  def g[T, U](x: T, y: U): T|U  def f1:
Float|String  def f2: Byte|String  def f3: String|Float|Byte  ***/
def main(args: Array[String]): Unit = {    val x = new Cell(f3)
x.other = 1f          // ok ( Float <:< Byte|Float|String)    x.other
= (1: Byte)   // ok (  Byte <:< Byte|Float|String)    x.other = "def"
     // ok (String <:< Byte|Float|String)    x.other = 1d          //
nope    // a.scala:15: error: type mismatch;    //  found   :
Double(1.0)    //  required: Byte|Float|String    //     x.other = 1d
  //               ^  }}

Will the videos from ScalaDays be available somewhere?

Simon Ochsenreither — 2013-06-10T16:14:00

... assuming that the talks will be recorded, of course.

Thanks,

Simon

dark magicks in the collections

Paul Phillips — 2013-06-10T07:47:58

How obvious is the problem with this class? (Maybe there are a lot of
problems with this class, but I think one problem is worse.) Is the problem
so obvious that people won't run into it? Is the behavior which underlies
it accomplishing something desirable most of the time; or even, more often
than not?

implicit class ExtensionMethods[A, CC[X] <: Iterable[X], Repr](coll: CC[A]
with TraversableLike[A, Repr]) {
  def bippy(implicit cbf: generic.CanBuildFrom[CC[A], Int, CC[Int]]) = coll
zip coll.map(_.toString.length)
}

I have never seen the behavior in question come up in any context other
than "it doesn't work" or some variation thereof. Do people really want
magic of this kind to happen without any explicit indication from the
programmer? Are you sure? Will all your collaborators see what the problem
with this class is?

If you intend to take a contrary position, I hope you will confirm that you
immediately saw the problem in the code above - before you looked at the
full example, which I will append after

Bug or a consequence of the lack of virtual classes?

Simon Ochsenreither — 2013-06-09T22:37:30

Hi everyone!

Consider these declarations:

  class Foo {
    class Bar {
      def foo = 1
    }
  }
  
  class SubFoo extends Foo {
    class Bar {
      def foo = 42
    }
  }

Let's create some instances:
  
  val foo = new Foo
  val fooBar = new foo.Bar
  fooBar.foo                                      //> res0: Int = 1

  val subFoo = new SubFoo 
  val subFooBar = new subFoo.Bar
  subFooBar.foo                                   //> res1: Int = 42

  val superFoo: Foo = subFoo
  val superFooBar = new superFoo.Bar
  superFooBar.foo                                 //> res2: Int = 1
  
The last result is a bit scary, because the syntax looks like dynamic 
binding, but the method is called on the static type instead.

Is this a bug, or expected, because Scala doesn't have virtual classes 
(yet)?

Thanks and bye,

Simon

consolidate def x and def x() functions

Radim Kolar — 2013-06-07T19:36:13

I'm not sure what the reasoning for having `def foo = ` and `def foo() 
=` outside of confusing the newly initiated
I don't buy the semantic difference reason
if empty arg lists were required, then you wouldn't need to distinguish 
var and def

proposal:
   make them same.
   function a() can be called by this.a as well and def a = can be 
called by a()

Cloneable

Paul Phillips — 2013-06-07T19:12:32

Shouldn't scala.Cloneable work like this: there is a synthetic signature of
type

  def clone(): "MyType"

and if you extend a class which has a Cloneable parent, you will be
abstract unless you implement this signature with your type? Why would
anyone want to work with guarantees like these (from the javadoc for
java.lang.Cloneable)

*Note that this interface does not contain the clone method. Therefore, it
is not possible to clone an object merely by virtue of the fact that it
implements this interface. Even if the clone method is invoked
reflectively, there is no guarantee that it will succeed.*
*
*
Note that I intentionally made the signature public, because

*By convention, classes that implement this interface should override
Object.clone (which is protected) with a public method.
*

By convention? What are we, savages?

customized default value for user defined type

Radim Kolar — 2013-06-07T10:57:48

if you create instance in type definition, it will be used as default 
value. If not then today functionality is unchanged

type five = new Integer(5)

then you can do

var x:five = _

x == 5

Syntax request: Allow type signatures in source.

Jeff Shaw — 2013-06-06T15:03:30

Hello all,
I've just recently started learning Scala. One thing I miss from Haskell is 
the ability to have clean type signatures and function definitions, since 
the two can be separate.

Here's an example from the vector package.

foldl :: Vector v b => (a -> b -> a) -> a -> v b -> afoldl f z = ...


It's easy to tell the type signature of foldl from the source without 
having to look at documentation. It makes it easier to figure out what 
foldl does and the order I should pass arguments.

Contrast the above with Scala.

override def foldRight[B](z: B)(op: (A, B) => B): B = ...

The types are inline with the definition, so that determining the type for 
foldRight requires mentally filtering out value names. I constantly find 
myself looking at HTML documentation which shows a cleaner representation 
of a function's type. Allowing something like the following in source would 
be a nice option.

override def foldRight : [B] (B) => ((A, B) => B) => B

def foldRight(z)(op) =
    reverse.foldLeft(z)((right, le

Scala style: function literals

Philipp Haller — 2013-06-05T23:38:39

Hi all,

Recently, I reviewed code with a mix of function literals and other expressions, such as

    onComplete { v => p complete { v map f } }

I agree with the syntax to pass function literals as follows:

    list map { el => <body> }

It reads very natural, and the function literal is clearly demarcated.

On the other hand, I'd prefer to pass expressions that are *not* function literals to be passed using regular parentheses:

    p.complete(v.map(f))

Note that I didn't write `p.complete(v map f)` because
a) I don't think the infix syntax is a good choice for `v map f`, since neither is `f` is a function literal nor is `map` a symbolic operator, and
b) for consistency `p.complete` should be invoked in the same way as `v.map`. 

Taken together I'd prefer to express the first example as follows:

    onComplete { v => p.complete(v.map(f)) }

What's interesting about this style is that it makes code where function literals appear interspersed with other expressions easy to read:

    that onComplete { c

Accessing defaultGetterName leads to type error

Simon Schäfer — 2013-06-05T14:11:36

Welcome to Scala version 2.11.0-20130603-221210-fb06073844 (OpenJDK 
64-Bit Server VM, Java 1.7.0_21).
Type in expressions to have them evaluated.
Type :help for more information.

scala> import scala.reflect.runtime.universe._
import scala.reflect.runtime.universe._

scala> class Foo(val i: Int, val j: Int = 0)
defined class Foo

scala> val tn = nme.asInstanceOf[scala.reflect.internal.StdNames#TermNames]
tn: scala.reflect.internal.StdNames#TermNames = 
scala.reflect.internal.StdNames$nme$< at >15b4a221

scala> tn.defaultGetterName(nme.CONSTRUCTOR, 1)
<console>:18: error: type mismatch;
  found   : reflect.runtime.universe.nme.NameType
     (which expands to)  reflect.runtime.universe.TermName
  required: _14.Name where val _14: scala.reflect.internal.StdNames
               tn.defaultGetterName(nme.CONSTRUCTOR, 1)
                                        ^

// different error message
scala> tn.defaultGetterName(nme.CONSTRUCTOR, 1)
<console>:18: error: type mismatch;
  found   : reflect.runtime.universe.nme.NameTy

Unpack tuple to var

Radim Kolar — 2013-06-04T23:06:57

proposed addition to scala language:

val t = (1,2,3)
var a,b,c = 10
( a,b,c ) = t

will do

a = 1
b = 2
c = 3

https://issues.scala-lang.org/browse/SI-7547

Repetition of type parameter bound

Simon Schäfer — 2013-06-03T21:50:13

Why am I forced to repeat the type bound A <: T in Y?

   trait T

   class X[A <: T](a: A)
   class Y[A <: T](a: A) extends X(a)

For the compiler it should not be necessary, it already knows the bound 
from X. So, is there a use case where it is necessary to force the 
programmer to repeat the type bound or is it just not implemented 
behavior / avoided for documentation purposes.

GSoC Scala 2013

Mayur Patil — 2013-05-30T07:27:16

Hello,

    Congratulations to Scala team !! 

    Total 9 projects are selected from 14 proposed list of Scala projects, 
Its a great achievement.

    My best wishes to Students and their Mentors.

    Have a fun learning and great coding Summer !!
*
--
Cheers,
Mayur*

repl bug? (value class array)

wang hongjiang — 2013-05-29T12:24:14

i'm using scala2.10.1

scala> class A(val i:Int) extends AnyVal
defined class A

scala> val arr = new Array[A](1)
arr: Array[A] = Array(null)

scala> arr(0)
java.lang.NullPointerException
    at .<init>(<console>:10)
    at .<clinit>(<console>)
    at .<init>(<console>:7)
    at .<clinit>(<console>)
    at $print(<console>)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at scala.tools.nsc.interpreter.IMain$ReadEvalPrint.call(IMain.scala:734)

I think the NEP may be caused by assign "null" to value class A , or type
inference ?

if i use scalac compile the file and run :

$ cat V.scala
class A(val i:Int) extends AnyVal;

object Main extends App{
  val arr = new Array[A](1);
  println("here=" + arr(0));
}

$ scalac V.scala && scala Main
here=null  // it's o

the only true constant is change

Paul Phillips — 2013-05-27T19:31:15

I noticed these aren't final in the scala.math package object:

val  E = java.lang.Math.E
val Pi = java.lang.Math.PI

That means your "area" method looks like this

         0: iconst_2
         1: i2d
         2: getstatic     #13                 // Field
scala/math/package$.MODULE$:Lscala/math/package$;
         5: invokevirtual #17                 // Method
scala/math/package$.Pi:()D
         8: dmul
         9: dload_1
        10: dmul
        11: dreturn

when it could look like this

         0: ldc2_w        #23                 // double 6.283185307179586d
         3: dload_1
         4: dmul
         5: dreturn

Is there some reason NOT to fold these constants? Anyone know if Oracle is
planning on changing the values of Pi or E in java 8?

Crazy thoughts: Unifying for{} comprehensions and {blocks}?

Haoyi Li — 2013-05-27T03:53:16

I've been thinking about this recently, and it's pretty far out, but bear
with me.

I don't pretend to speak for everyone, but from my personal experience, the
big blocker from converting code from a "normal" style:

val x = {
  val a = 2
  val b = 3
  val c = 4
  println("Debug: " + (a + b))
  a + b + c
}

into a monadic style using for comprehensions:

val x = {
  val a = 2
  for{
    b <- List(1, 2, 3)
    c = 4
    _ = println("Debug: " + (a + b))
  } yield a + b + c
}


Is the fact that it is effectively a complete re-write:

- you need to put the *for* at the top
- the *yield* at the bottom
- move any assignments before the first <- outside the for{}'s body
- move the final expression outside the curly braces
- change any bare statements (like the println) into an awkward assignment
to _

These changes are in addition to the monadic <- statements, which are new
semantics, so it's acceptable that they need new syntax.

One thing of note is that all these changes you have to perform are *purely
cosmetic*

Reference equality and value equality

Rich Oliver — 2013-05-26T13:43:30

Just thinking about Reference equality and value equality and whether they 
are fundamentally the same method at all and if there is any virtue to 
having them unified apart from compatibility with the Java ecosystem. 
Reference equality means isSameObject would it not be better to have a 
differnet method name / symbol combination?