gmane.comp.lang.scala.debate

Better Tuple Syntactic Sugar

wookietreiber — 2012-05-26T10:38:34

Hi there,

I'd like Scala to better support tuple syntax, consider the following
example:


Instead of being able to that, currently I have to go the long way:


It is already possible with for expressions:


So why not with e.g. functions like in the example above?

Default-Value Type Parameter and Named Type Arguments

Chris Hodapp — 2012-05-26T04:11:06

There is demand, it would seem, from myself and from others for supporting 
named type arguments and default values for type parameters. I was asked by 
Chris Vogt (my GSOC mentor) whether I would be willing to look at 
implementing these features, and I said I would.

I plan to write a SIP that specifies how these should work, should an 
agreement on the issue be reached here.

My current idea for basic naming support is something like this for naming 
would look something like:
"""
class A[T, U]

val a1 = new A[Int, String]         // Call normally
val a2 = new A[T = Int, U = String] // Provide names to make meaning clear
val a3 = new A[U = String, T = Int] // Reverse names, still works
val a4 = new A[Int, U = String]     // Provide as many position-resolved 
arguments as desired before providing name-resolved arguments
"""

My current idea for basic default support would look like:
"""
class B[T = String]

val b1 = new A[String] // Explicitly provide the default type
val b2 = new A[Int]    // Provide a di

Parentheses instead of curly-braces around case-lambdas?

Luke Vilnis — 2012-05-25T12:25:56

Apologies if this has been asked before - I did a brief search and couldn't
find anything.

Would it be possible to allow case-lambdas within parentheses (instead of
braces) in a future version of Scala?

The idea is just to allow "(case pat (if cond)? => expr)" to mean the same
as "{ case pat (if cond)? => expr }", at least when inside an argument list
(but hopefully anywhere inside parentheses). So we could write things like:

Map("asd" -> 123).map(case (k, v) => (k, v + 1))

or even lose the parentheses when in a multi-argument list:

multiArgumentMethod(case (x, hd::tl) => x::tl, case (x, Nil) => x::Nil)

or whatever. For ambiguity's sake, we couldn't allow it outside of
parentheses, and maybe not outside of argument lists at all (but I don't
think we'd have to go that far):

val f = case (a, b) => a + b // No!
val f = (case (a, b) => a + b) // Maybe?

As far as I can see, this shouldn't be ambiguous in the grammar, but I
could definitely be missing something.

Thanks,
Luke

P.S. Justification for additi

Mailing list reminder: Scala-debate

Scala Mailing Lists — 2012-05-21T13:32:02

Welcome to the "Scala-debate" mailing list.

This automatic reminder is sent once a month to the list,
to keep subscribers up-to-date with the mailing list services,
and to help keeping the list on topic.

-------------------------------------------------------------------

The "Scala-debate" mailing list:

This list is a more relaxed forum for Scala discussions
that would probably be off-topic or too convoluted for
the other lists, but that may still be quite interesting
to follow for a selected readership.

In particular, the following are appropriate:

  * threads that evolved beyond their initial topic,
      and have become too long or convoluted to be
      of interest to most readers
  * threads discussing extremely specialized topics
  * threads that are mostly speculative in nature,
      out-of-the-box thinking, philosophical views
      (as long as they are still somehow related
      to Scala)
  * debates (of course)

The "Scala-debate" list is the natural destination of all
the threads that star

Object identity

Paul — 2012-05-20T20:45:20

You can use the `eq` operator for checking for object identity with any 
AnyRef object in Scala.

Wouldn’t it be more elegant to rename this to `is`. This way, you could 
write more readable code

    if (a is b) ...

What do you think?

Regards, Paul

Could the Manifest generation be implemented by a macro?

Andrés Testi — 2012-05-18T19:49:59

Currently the compiler does magic to generate Manifests on demand:

def foo[T](implicit Manifest[T]) = ...

foo[FooClass]<<Compiler generates a Manifest for FooClass in the foo 
invocation point>>

Could this compiler task, be replaced by a macro in a future version of 
Scala?

object Predef{
  
  implicit def manifest[T]: Manifest[T] = macro manifestImpl

  def manifestImpl[T](c: Context): Expr[Manifest[T]] = {
    // generate a Manifest for T
    ...
  }
}

Regards.

- Andrés

right-biasing Either

Jason Zaugg — 2012-05-14T07:08:34

(A follow-up from ticket SI-5793. [1])

Apologies in advance to any left-handers out there.

I propose (not that I'm the first) to right-bias Either. Concretely,
this means we would add map/flatMap etc directly to Either, rather
than going through RightProjection. RightProjection could probably
deprecated.

Is there any previous discussion on this? Any arguments against?

-jason

[1] https://issues.scala-lang.org/browse/SI-5793

[scala-humor] Symbols in Scala (Was: How to represent Symbol? Was: compile scala-compiler: done!

Som Snytt — 2012-05-13T19:56:46

If the Scala team were The Avengers, which superhero would each of them be?

To encourage free creativity, there are no strictures: it's not necessary
that Martin is Nick Fury, or that Heather has to be Black Widow.  Wikipedia
says Black Widow has:

psychological conditioning that suppresses her memory of true events as

I think that applies to anyone who has looked at a bug report.

Certainly, the following would explain how Martin was able to play an
important role in ancient tech like Java as well as future tech like Scala:

Fury takes a special medication called the Infinity Formula that halted his

As a nod to tail recursion, our Nick Fury takes Ouroboros Juice.  Same
formula, different flavor.  (Now with Vitamin Trampoline!)

Apparently, it's also OK to create new superpersonae as warranted:

The rotating roster has become a hallmark of the team, although one theme

Bonus points for identifying the former villains!

I know I'm not alone in saying: Thank-you, Team Scala, wherever you are!

---------- Or

Experiences with SIP-18

Rex Kerr — 2012-05-08T15:12:10

I decided to give 2.10 M3 a try and see how SIP-18 affected my code; I
tried compiling one of my most heavily-used sets of code (library +
applications).

First, I noticed dozens and dozens of implicit conversion methods where
instead of writing def whatever(jlc: JavaLibClass) ... I would enrich
.whatever onto that class.  In 2.10 I'd use implicit classes instead for a
majority of these (probably 80%--actually, I'd use an even lighter weight
extension method syntax if I could), so I just turned on
-language:implicitConversions and forgot about them.

Then I found a dozen or so places where the compiler had unhelpfully
decided to generate structural types instead of using an anonymous class;
there were zero cases where the structural typing was the right thing for
the compiler to do in the first place, but I was grateful that it at least
told me what it had done so I could fix it.  After fixing these, no
warnings remained.

There were another dozen or so postfix op warnings.  One was just a
trailing method na

< at >transient object.

Aleksey Nikiforov — 2012-05-08T05:14:35

I was expecting a nested "< at >transient object" to work or to generate an
error. Instead the compiler silently accepted the annotation and then
simply ignored it.
I think there is a good use case to allow nested transient objects.
However, if there are objections against it, the compiler should generate
an error or at least a warning.

Test code:

object ExpMain {

  def main(args: Array[String]) {
    import java.io._

    val test = new TransientTest
    test.nested.value = 1
    test.transientNested.value = 1

    val bytes = new ByteArrayOutputStream
    val out = new ObjectOutputStream(bytes)
    out.writeObject(test)
    out.close()
    val in = new ObjectInputStream(new
ByteArrayInputStream(bytes.toByteArray))
    val restored = in.readObject.asInstanceOf[TransientTest]

    println("nested.value equal: " + (test.nested.value ==
restored.nested.value))
    println("transientNested.value equal: " + (test.transientNested.value
== restored.transientNested.value))
  }
}

class TransientTest extends Serializa

Macros vs string interp

Ken Scambler — 2012-05-07T15:09:47

I used to be sceptical of macros in Scala, and pine for string
interpolation.  However, the more I read and experiment with macros, the
more useless string interpolation looks.  Macros are a perfect fit for the
language: simple, elegant, powerful, and orthogonal.  String interpolation
appears to fail on these counts.

SIP-11 goes further than a simple s".." syntax to avoid backwards-compat
problems, and adds a whole new concept to the language: a "string prefix"
concept, which can be extended ad hoc by users.  Originally this had many
good use-cases beyond simple interpolation -- statically checked XML, JSON,
and quasiquoting for macros.

The thing is, the discovery of reify() makes all of these advanced use
cases completely redundant.  In his Scala days keynote, Martin notes that
the scala"..." literal string wasn't very interesting any more, because of
macros -- doesn't the same apply to the other examples?  Why have a feature
that gives you xml"$foo" when you can already do xml("$foo") or "$foo".xml
with

A "memoized" modifier for function caching proposal

Nikita Volkov — 2012-05-04T11:45:36


Memoization is an optimization technique when function evaluation results 
get cached by the set of passed parameters. This allows to evaluate the 
function only at the first time it is called with a specific set of 
arguments and return the cached results on all the consecutive calls with 
the same set of arguments.

You can think of it as of a more general lazy that also distinguishes the 
parameters. Thus memoization on functions with no arguments, such as memoized 
def functionWithNoParameters: String will have absolutely the same effect 
as lazy val functionWithNoParameters: String.
Some Use Cases1. Functions with heavy calculations

    memoized def calculateSomething(a: Int, b: Int): String = {
      // some heavy calculations take place here
    }

    calculateSomething(1, 2)    // since it's the first time the function is called with 
                                // parameters `(1, 2)` it will actually evaluate, then
                                // it will store the result in cache and retu

Example code: A toString method with a formatstring as an argument (pimp-the-library)

Ko Stoel — 2012-05-03T20:09:50

Hi,

I wanted an extra toString method with a formatstring as argument. Below 
the code :

//kos:  tested with Scala IDE for Eclipse 
2.1.0.nightly-2_10-201204300848-ba52ed6
object MyMain extends App {
  // making the toString method somewhat more versatile
  // the  'implicit class' construct for such a pimp-my-library
  // should rather be used, I believe
  implicit def more_toString_methods(x: Any): {
    def toString(formatstr: String): String
  }
  = new {
    def toString(formatstr: String): String = formatstr.format(x)
  }

  // testing it
  val tx=3456
  
  println(123456.toString)
  // output: 123456
  println(123456.toString("Hello  %,d   "))
  // output: Hello  123.456 
  println("Er was eens Scala".toString)
  // output: Er was eens Scala
  println(s"there $tx".toString("Hi %s, ") + "how" + 
"wonderfullyisdit".toString(" %-10.10s"))
  // output: Hi there 3456, how wonderfull
}

kind regards,
ko stoel [NL]

Scala >= 2.9 and mockito

Johannes Rudolph — 2012-05-03T14:48:15

Just wanted to share a recent experience how a subtle change in
compilation strategy can lead to problems.

Starting with Scala 2.9 it seems to be impossible to properly mock
classes extending traits with mockito. That's because mockito won't
mock bridge methods for some reason. After some digging I found out
that the only difference seems to be that starting with Scala 2.9
forwarder methods to trait implementations are marked with
`ACC_BRIDGE`.

http://code.google.com/p/mockito/issues/detail?id=340

Maybe it's mockito's fault. Just wanted to put that on record here as well.

Where does partest put its output?

Geraint — 2012-04-30T11:08:14

Using partest to run a bunch of scala tests retsults in output that looks 
like this...

Testing individual files
testing: [...]/files/run/bugs2087-and-2400.scala                      [  
OK  ]

When tests fail, you get [FAILED] instead of [  OK  ].

How do I find out how a test has failed? There's not much I can do with 
just [FAILED]. Are there any log files?

Using embedded SQL in Scala

Kangmo Kim — 2012-04-29T18:04:01

Hi, 
I am wondering if somebody can give me early feedback on my open source 
project ToySQL.(http://toysql.codeplex.com/).
 
ScalaQuery is great, but learning curve is high. So I decided to implement 
a DSL which looks similar to SQL. 
 
I would like to collect early feedbacks. Is a DSL like below something 
necessary for Scala programmers?
 
object TestSQL extends ToySQL {
def main(args:Array[String]) = {
EXEC (CREATE TABLE 'emp ('eno INTEGER, 'dno INTEGER, 'name CHAR(10)))
EXEC (INSERT INTO 'emp VALUES(1, 1, "kmkim"))
EXEC (INSERT INTO 'emp VALUES(2, 2, "jdlee"))
EXEC (INSERT INTO 'emp VALUES(3, 1, "kumdory"))
EXEC (INSERT INTO 'emp VALUES(4, 1, "wegra"))

EXEC (SELECT ('eno, 'name) FROM 'emp ORDER_BY ('eno ASC)) 
EXEC (SELECT ('eno, 'name) FROM 'emp ORDER_BY ('eno DESC)) 

EXEC (DELETE FROM 'emp WHERE 'eno < 3) 
EXEC (SELECT ('eno, 'name) FROM 'emp) 
EXEC (SELECT ('eno, 'name) FROM 'emp WHERE 'eno === 4)
EXEC (DELETE FROM 'emp)
EXEC (DROP TABLE 'emp)

EXEC (CREATE TABLE 'dept ('dno INTEGER, 'dname CHAR(1

Macro vs. Makro

Joa Ebert — 2012-04-29T10:50:51

Hello,

is there any particular reason why the package regarding macro expansion is 
called scala.reflect.makro whereas the keyword is called "macro"? 
Would it make sense to rename scala.reflect.makro to scala.reflect.macro 
before the 2.10 release?


Best,

Joa

Scala Advocacy

cwhii — 2012-04-26T18:51:03

A quick look at a few pages of http://StackOverflow.com shows a
contrast in the level of expertise in Java vs Scala programmers asking
questions. In two samples of questions asked with tags "java" or
"scala" only 8% of the Java questioners have reputations over 1000
whereas for Scala it is 43%.

I suspect that Scala level (beginner to expert, application programmer
to library designer) http://www.scala-lang.org/node/8610 of
questioners on SO is leaning a bit towards the high end. This produces
much more complex discussions for Scala than the ones for Java.

This post is intended to provoke a discussion on how to encourage more
questions that relate to the beginner and application programmer
because I assume this would help in the advocacy of Scala.

REPL constructor completion?

Alex Cruise — 2012-04-23T18:23:59

I searched JIRA for a few minutes but couldn't find any existing
enhancement.

In a dystopian Java world...

With savage constructor overloading...

...it'd be nice to be able to say new Foo(<tab> and see stuff.

If anyone is aware of a preexisting enhancement ticket, or thinks this is a
bad idea, please pipe up. :)

It doesn't need to be a huge priority, because you can always get a badly
formatted list of the overloads by entering an invalid constructor, e.g.:

scala> new Foo(nonsensical)
<console>:11: error: overloaded method constructor Foo with alternatives:
  ...

-0xe1a

Some HBase Ideas (Hosted on Github)

Jacob Groundwater — 2012-04-22T11:11:33

I was dreaming one lazy afternoon and had a few ideas for Scala HBase 
libraries. I put what I came up with here:

https://github.com/jacobgroundwater/Scala-HBase/wiki

I would love any feedback or critiques.

Thanks!

Mailing list reminder: Scala-debate

Scala Mailing Lists — 2012-04-21T13:32:02

Welcome to the "Scala-debate" mailing list.

This automatic reminder is sent once a month to the list,
to keep subscribers up-to-date with the mailing list services,
and to help keeping the list on topic.

-------------------------------------------------------------------

The "Scala-debate" mailing list:

This list is a more relaxed forum for Scala discussions
that would probably be off-topic or too convoluted for
the other lists, but that may still be quite interesting
to follow for a selected readership.

In particular, the following are appropriate:

  * threads that evolved beyond their initial topic,
      and have become too long or convoluted to be
      of interest to most readers
  * threads discussing extremely specialized topics
  * threads that are mostly speculative in nature,
      out-of-the-box thinking, philosophical views
      (as long as they are still somehow related
      to Scala)
  * debates (of course)

The "Scala-debate" list is the natural destination of all
the threads that star