Rado Buranský | 24 Feb 21:50 2015
Picon

Extremely slow patmat phase of compilation

Can anybody tell me why this code takes endless time  to compile? What is the compiler doing so much and how can I help it?

You can find full source code here:
https://gist.github.com/RadoBuransky/d1d763a8f3c6555ee89a

sealed trait C
case object C1 extends C
case object C2 extends C
case object C3 extends C
...
case object C399 extends C
case object C400 extends C

object M {
  def f(c: C): Int = c match {
    case C1 => 1
    case C2 => 2
    case C3 => 3
    ...
    case C399 => 399
    case C400 => 400
  }
}

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Matthew Pocock | 18 Feb 14:03 2015
Picon

verbose enhancement syntax

I often end up with a typeclass and a syntax that converts each method of the typeclass to act as infix notation.

trait Foo[T] {
  def asString(t: T): String
  def asInt(t: T): Int
}

implicit class FooSyntax[T](val t: T) extends AnyVal {
  def asString(implicit foo: Foo[T]): String = foo.asString(t)
  def asInt(implicit foo: Foo[T]): Int = foo.asInt(t)
}

This is an extremely boring and mechanical re-write. Is there some way that we can manufacture the syntax mechanically from the typeclass?

Matthew

--
Dr Matthew Pocock
Turing ate my hamster LTD

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

skype: matthew.pocock
tel: (0191) 2566550
mob: +447535664143

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Eric Kolotyluk | 17 Feb 17:27 2015
Picon

Exhausting Akka Receive

In http://doc.akka.io/docs/akka/snapshot/scala/actors.html it gives the example
  1. import akka.actor.Actor
  2. import akka.actor.Props
  3. import akka.event.Logging
  4.  
  5. class MyActor extends Actor {
  6. val log = Logging(context.system, this)
  7. def receive = {
  8. case "test" => log.info("received test")
  9. an>case _ => log.info("received unknown message")
  10. }
  11. }
Wouldn't it be better practice to use
  1. import akka.actor.Actor
  2. import akka.actor.Props
  3. import akka.event.Logging
  4.  
  5. class MyActor extends Actor {
  6. val log = Logging(context.system, this)
  7. def receive = {
  8. case "test" => log.info("received test")
  9. case message: Any => log.error(s"received unknown message = $message")
  10. }
  11. }
First off, having better diagnostic information in the log is a good thing, is it not? Why does so much Scala documentation take the lazy way out and only ever give the bare essentials. Why does Scala documentation so rarely go a little further and demonstrate some better practices, especially when it is trivial to do?

Second, an unknown message is an error, it's not just information.  Often people, and monitoring systems, ignore "info" messages, and only pay attention to warnings, errors, and worse. There seems to be this general sense of laziness in the Scala, Akka, Play, etc. community to ignore problems, and train others to ignore them as well.

Coming from a Java background, the Scala community seems to just care less about quality, and more about typing less.

- Eric

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Som Snytt | 11 Feb 19:04 2015
Picon

Escaped quote and dollar in interpolations

I added escaped dollar to the PR for ordinary backslash escapage in interpolations.

After spending some time using the format interpolator, where indexed args in a format string require raw dollars, I found that I could no longer distinguish double dollars from just seeing double.

Suggestions and, especially, +1s welcome.
The commit messages:

Everyone wants to say `s"\"hello,\" world"`. This commit considers `\"` when looking for the end of a string part. `\\` is permitted to enable `\\"` for literal `\"`. However, the interpolator still receives the source text. The wrinkly edge case is that trailing backslash must be escaped. For instance, an interpolator that creates `File` objects would require `F"~\Documents\\"`. Improve error message for unterminated string to highlight quoted quote behavior.and

Everyone wants to say `s"\$s to donuts"`. The double-dollar is especially onerous in format strings: ``` f"$pi %1$$.1f" ``` compared to ``` f"$pi %1\$.1f" ``` and regular expressions ``` scala> s"^hi$$".r res0: scala.util.matching.Regex = ^hi$ scala> s"^hi\$".r res1: scala.util.matching.Regex = ^hi$ ``` This commit makes dollars escapable in the way everyone expects, but retains the double-your-dollars escape for compatibility. However, "\$", escaped dollar in an ordinary string literal, is not tolerated. This is deemed good behavior because everyone should use the f-interpolator all the time, even for constant strings. That way, you'll never see the missing-interpolator lintage.


--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Alois Cochard | 10 Feb 13:32 2015
Picon

Implicits with same name make inference fail.

Hey all,

I'm curious that bug, you know, when you have to implicits with the same in scope and the compiler tell you no implicit can be found.

I think it's really bad, because the error message is wrong he should warn about ambiguity or abuse of shadowing... IDK, but the current situation is really problematic.

It can sometime can quite a while to find that -in fact- to impl. with the same name are in scope.

Was there already discussion about this? Do we have hope to fix this?

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Russ P. | 10 Feb 09:07 2015
Picon

alternative default argument syntax

Consider the syntax for default argument values:

def foo(bar: Int = 0)

I am wondering why this can't be written as

def foo(bar = 0: Int)

The latter seems more logical to me because the assignment is to the value, not the type. Is there some technical reason that this would cause problems? If not, I say give me that option.

While we're at it, why can't I just write

def foo(bar = 0)

and let the type be inferred? It would be consistent with type inference in general. I have seen this proposed before, but I don't seem to see any SIP on it and I don't know where it stands. Has it been officially rejected or just forgotten? Thanks.

--Russ P.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Tomás Lázaro | 3 Feb 18:30 2015
Picon

Scala Style Guide: Braces in cases

Hi everyone,

I'm helping out a team new to Scala and told them to follow the official style guide. Many times I asked them to remove braces inside case statements since those are not necessary and just add clutter. They found, to my surprise, that the official style guide actually encourages using braces there:

case - Omit braces if the case expression fits on a single line. Otherwise, use curly braces for clarity (even though they are not required by the parser).

To me this is unprecedented, for instance, take a look at Akka's source code, braces aren't used there: https://github.com/akka/akka/search?utf8=%E2%9C%93&q=case .
Take a look at Programming in Scala, 2nd Edition, Chapter 15 - Case Classes and Pattern Matching, page 298, Listing 15.21: multiple lines inside case, no braces.

Do we really want the standard to enforce braces in those places? It would imply that on every case of a receive method using Akka we should use those extra braces when multi-line.

Please let me know what you think.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Sisso | 27 Jan 18:19 2015
Picon

I should argument that Option.apply() is bad (bad) practice?

Hello guys.

In a project some guys started to replaces Some(x) by Option(x) everywhere. The argument is that use Option(x) is a good practice because automatic translate nulls into None. Option(x) is very nice for java integration, but for me, I want that my program to explode if anything receive a null. And not hide it.

Comments?

[]s,
Sisso

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Owen | 17 Jan 23:12 2015
Picon

Why does zipping Options not produce an Option?

But the full signature shows that this is not exactly explicit; it's supposed to come out to an Option due to the CanBuildFrom magic. But I don't really understand CanBuildFrom that well...

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Som Snytt | 16 Jan 18:50 2015
Picon

Fwd: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo

They said, "Fix ALL the Xlint warnings!"

We would say, "Fix _ the Xlint warnings!"

---------- Forwarded message ----------
From: joe darcy <joe.darcy <at> oracle.com>
Date: Thu, Jan 15, 2015 at 7:36 PM
Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo
To: jdk9-dev <at> openjdk.java.net


Hello,

After a small language change to make the effort tractable [1], and another round of code cleanup [2], the deprecation warnings have been eliminated from the build of the jdk repository of JDK 9 [3].

That means that coming after the previous waves of warnings cleanup, *all* the lint warnings are now enabled in the build of the jdk repo!

The effort of clearing all these lint warnings has taken place over many months building on the contribution of many people. I'd like to especially recognize Stuart Marks and Alan Bateman for early work cleaning up the libraries, Jan Lahoda for implementing the supporting language change, Jason Uh for help running build jobs, and Phil Race for many reviews of changes to client code.

Thanks,

-Joe

[1] JEP 211: Elide Deprecation Warnings on Import Statements, http://openjdk.java.net/jeps/211

[2] JDK-8066616 Suppress deprecation warnings in jdk libraries, https://bugs.openjdk.java.net/browse/JDK-8066616

[3] http://hg.openjdk.java.net/jdk9/dev/rev/f1dc16345985


--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Ken Scambler | 13 Jan 00:58 2015
Picon

On the anti-modular traps of trait usage

As a counterpoint to Julian's thread about whether classes are necessary, I'd like to take this opportunity to complain/rant bitterly about popular anti-modular patterns of trait usage.

Traits shine as pure interfaces, typeclasses and as a kind of an abstraction over modules in the ML sense.

However, too frequently they are used as mixins in a way that exposes implementation details and couples all kinds of things together in a big mess.  It's often hard to untangle codebases written this way, and libraries that are written this way are all but unusable.

A common example is where the trait is a pseudo-OO-class, with methods that share data or state expressed through other fields:

trait BananaMasher {
  def banana: Banana
  def masher: Masher

  def mashBanana: Mush = masher.mash(banana)
}

trait BananaPeeler {
  def banana: Banana
  def peeler: Peeler
 
  def peelBanana: Peel = peeler.peel(banana)
}

trait Logging {
  def logger: LoggerImpl

  def info(str: String): Unit = logger.info(str)
  def error(str: String): Unit = logger.error(str)
}

class BananaManager extends BananaMasher with BananaPeeler with Logger {...}

The lovely "with" syntax looks and quacks like composition; it looks lovely!  We just throw everything together and it works...ish.

The trouble is that true composition should entail things not getting more complicated as you combine them.  In this case, BananaManager's API contains _everything_ provided by all the mixins, and all the wires are exposed, and its namespace is filled with gunk.  To understand BananaManager, you need to know _everything_ about all its mixins.  That isn't composition, that's ....accretion, or something!

There is a secret handshake between BananaPeeler and BananaMasher; there is a Banana field called "banana".  Is it deliberate? Do they rely on this as a way of talking to each other? Is it just an accident and this will result in a subtle bug?  Who knows!

You can see Logging thrown in -- this is a hard-wired side-effect, with a logging implementation baked in.  How will it be used by subclasses? What uses the effect? Who knows!

There is an illusion of flexibility given by the fact that all the details are overrideable as fields in the final cakey-muddle.  This is like that old cherished Spring ideal of "expose every wire in everything" that provides maximum configurability at the expense of any ability to figure out what anything is doing in isolation of everything else.

There is an illusion of modularity given by the sexy creation syntax: new This with That with TheOther; however it accumulates and exposes detail, that might interact in unpredictable ways.  Tests need to make all kind of unnecessary decisions on how to navigate the uncertainty and "togetherness".

It breaks my heart to see such a powerful language fall victim to the siren song of a sexy feature that can result in code that is often _worse_ (less modular, composable) than in more feature-poor languages! 

Scala gives us all the tools we need to write clean, modular, well-factored code.  Please consider trait usage carefully.

Cheers,
Ken

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Gmane