David Barri | 16 Dec 09:40 2014
Picon

Deciphering big, long type errors

Hello,

Often, scalac spits out big, long, menacing error messages like this:

... type mismatch;
[error]  found   : blah.webapp.client.lib.ui.Editor[(blah.webapp.base.data.Validators.blar.scala.S, (String, String, blah.webapp.base.data.ImplicationRequired)),blah.webapp.client.app.ui.CfgBlars.fields.FieldValue,scalaz.effect.IO,blah.webapp.client.app.ui.CfgBlars.storesAndState.S,blah.webapp.client.app.ui.CfgBlars.fields.Field,scalaz.effect.IO[Unit],(japgolly.scalajs.react.vdom.ReactVDom.Tag, japgolly.scalajs.react.vdom.ReactVDom.Tag, japgolly.scalajs.react.vdom.prefix_<^.Tag)]
[error]     (which expands to)  blah.webapp.client.lib.ui.Editor[((Stream[blah.webapp.base.data.CustomBlar], Option[blah.webapp.base.data.CustomBlar.Id]), (String, String, blah.webapp.base.data.ImplicationRequired)),blah.webapp.client.app.ui.CfgBlars.fields.FieldValue,scalaz.effect.IO,blah.webapp.client.app.ui.CfgBlars.storesAndState.State,blah.webapp.client.app.ui.CfgBlars.fields.Field,scalaz.effect.IO[Unit],(japgolly.scalajs.react.vdom.ReactVDom.TypedTag[japgolly.scalajs.react.ReactElement], japgolly.scalajs.react.vdom.ReactVDom.TypedTag[japgolly.scalajs.react.ReactElement], japgolly.scalajs.react.vdom.ReactVDom.TypedTag[japgolly.scalajs.react.ReactElement])]
[error]  required: blah.webapp.client.lib.ui.Editor[?,?,scalaz.effect.IO,Bleh.this.thing.sas.S,?,scalaz.effect.IO[Unit],?]
[error]     (which expands to)  blah.webapp.client.lib.ui.Editor[?,?,scalaz.effect.IO,Bleh.this.thing.sas.State,?,scalaz.effect.IO[Unit],?]


To me that's as good as incomprehensible, so I wrote a little Scala script to parse error messages like above and turn them into this:


----------------------------------+-+-----------------------------------------------------------
Found                             | | Required
----------------------------------+-+-----------------------------------------------------------
blah.webapp.client.lib.ui.Editor[ | | blah.webapp.client.lib.ui.Editor[
  ?,                              |?|   (
                                  | |     (
                                  | |       Stream[
                                  | |         blah.webapp.base.data.CustomBlar],
                                  | |       Option[
                                  | |         blah.webapp.base.data.CustomBlar.Id]),
                                  | |     (
                                  | |       String,
                                  | |       String,
                                  | |       blah.webapp.base.data.ImplicationRequired)),
  ?,                              |?|   blah.webapp.client.app.ui.CfgBlars.fields.FieldValue,
  scalaz.effect.IO,               | |   scalaz.effect.IO,
  Bleh.this.thing.sas.State,      |≠|   blah.webapp.client.app.ui.CfgBlars.storesAndState.State,
  ?,                              |?|   blah.webapp.client.app.ui.CfgBlars.fields.Field,
  scalaz.effect.IO[               | |   scalaz.effect.IO[
    Unit],                        | |     Unit],
  ?]                              |?|   (
                                  | |     japgolly.scalajs.react.vdom.ReactVDom.TypedTag[
                                  | |       japgolly.scalajs.react.ReactElement],
                                  | |     japgolly.scalajs.react.vdom.ReactVDom.TypedTag[
                                  | |       japgolly.scalajs.react.ReactElement],
                                  | |     japgolly.scalajs.react.vdom.ReactVDom.TypedTag[
                                  | |       japgolly.scalajs.react.ReactElement])]
----------------------------------+-+-----------------------------------------------------------


I find the above much more useful and assume many others would too.
Consequently, I'd like to share it with others in similar need.

Secondly, would there be interest in adding a derivative of this to scalac itself?
(It's literally just a complicated String ⇒ String.)

Cheers. Enjoy.
DB

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

Scala mailing list archive exposes emails to spam!

I apologize for posting off-topic, but I was unable to find a better method to contact the list moderators.

The old Scala mailing list archive, hosted on scala-lang.org exposes everyone's un-escaped email addresses to spam harvesting.
You can clearly see un-espaced emails in the quoted text, conveniently combined with a mail-to tag.

I hope Scala team takes this seriously, so we can experience a decrease of spam in our mailboxes.

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

Keyword arguments in extractors

I'm sure this must have been considered at some point, but it would be really useful to be able to select particular fields for extraction in match statements, analogous to the way keyword arguments are handled in constructors. If I had a case class:

case class Person(
  firstName
: String,
  lastName
: String,
  gender
: Gender,
  height
: Double,
  weight
: Double,
  wearsGlasses
: Boolean,
  address
: String,
  city
: String,
  state
: String,
  country
: String)

It would be really lovely to be able to match on a subset of fields without using a whole bunch of placeholders. The syntax could be parallel to a method call:

person match {
 
case Person(wearsGlasses = wearsGlasses, height = height) if height < 6.3  => // some calculation
 
case _ => // some other calculation
}

This could be a little confusing to remember which side of the equals sign is the keyword and which is the variable to bind, but probably not so bad because a) keyword = variable matches the order for calling a constructor/method with keyword args and b) most of the time it's logical to spell the keyword and the variable the same way, unless you're trying not to shadow another identifier with that name. Alternatively, variable <- keyword might be used to somewhat parallel for-comprehensions.

Presumably, this might be limited to work only for case classes with the default `unapply`, within case clauses, since `unapply` doesn't generally provide names.

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

Guards in varargs method calls

I fairly frequently run into a situation where I want to include an item in a data structure only if a condition holds. Imperative programming supports this pretty naturally with a mutation inside an if statement. I find it really cumbersome to get the same result when programming with immutable data structures. I might write something like:

(
 
List(
   
"Item 1",
   
"Item 2"
 
) ++
 
(if (myCondition) List("Item 3") else Nil) ++
 
List(
   
"Item 4"
 
)
)

It would be great if varargs supported guard on elements, which would let me do:

List(
 
"Item 1",
 
"Item 2",
 
"Item 3" if myCondition,
 
"Item 4")

I'm not sure if this exact syntax would work, but I run into this situation all the time, particularly when populating data structures of expected formats, for APIs and things like that.

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
André van Delft | 4 Dec 15:31 2014
Picon

"while" in for-comprehensions

In 2007 Martin wrote the following in the Scala language newsgroup:

I don't like break because it mixes the `yield' part of a 
comprehension (what should be returned for each element?) and the 
generator (what elements to iterate over?). A less intrusive change 
might be to add a `while' clause to comprehensions, to be translated 
to `takeWhile'. E.g. 

  for (val i <- x until y while !isPrime(i)) yield i * i 

would be expanded to 

  (x until y) takeWhile (i => !isPrime(i)) map (i => i * i) 

The advantage here is that most sequences already have a takeWhile method. 
What do people think about this? 

 -- Martin 

There was only 1 response at the time, positive. 
Has there been more discussion thereafter on this suggestion?
I would welcome this change.



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

Generic string interpolator

Hi all,

  Is it possible to create a string interpolator with type parameter? Something like

implicit class MyHelper(val sc: StringContext) extends AnyVal {
  def foo[T](args: Any*) = { ... }
}

  I have an interpolator implemented as a macro and want user to pass type parameter there, to perform some additional checking. This type is not related neither to the args types, nor to the return type directly.

--
Regards,
Mike.

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

Question about member modifiers in the 2.11-spec

It seems as if the section on qualified member modifiers (http://www.scala-lang.org/files/archive/spec/2.11/05-classes-and-objects.html#modifiers) has been copied between the private and the protected subsection. Notably, the spec says

An different form of qualification is private[this]. A member M marked with this modifier is called object-protected; it can be accessed only from within the object in which it is defined. That is, a selection p.M is only legal if the prefix is this or O.this, for some class O enclosing the reference. In addition, the restrictions for unqualified private apply.

… and just in the section below

A different form of qualification is protected[this]. A member M marked with this modifier is called object-protected; it can be accessed only from within the object in which it is defined. That is, a selection p.M is only legal if the prefix is this or O.this, for some class O enclosing the reference. In addition, the restrictions for unqualified protected apply.

The reason I looked at these sections was to figure out the difference between private[sassafras] and protected[sassafras]. Hopefully someone can clear that up for me too :)

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

Recent announcements by Microsoft and Scala .Net

Hello,

I'm coming mainly from .Net background but quite interested in Scala as a language. From the (relatively) recent additions to mainstream and close to mainstream languages I see it as the one having the closest resemblance to C-inspired languages, while providing great benefits both in OOP and FP spaces.

However, as somebody who develops enterprise software with fat clients for Windows machines, I cannot use the language in my everyday job, which I would like very much. Of course, there is F#, which is a great language by itself, but it looks and feels so different compared to the mainstream C# that it will be very hard to convince anybody using it, and it lacks many OO features Scala has.

I know that the .Net effort has been abandoned sometime in 2012, as I understand, because of no interest from Typesafe and difficulties to marry the Scala and the CLR generics. But there are two factors that surfaced recently which make me think about viability of the .Net backend for Scala:
a. Recent announcement by Microsoft about open-sourcing the .Net platform
b. Project Valhalla which talks, among other things, about possible inclusion of reified generics in JVM

As I see it, the former may increase community's interest/involvement in the .Net platform as a whole. And the later, if I understand correctly, will require from Scala to evolve in a way which will end in some kind of support for platform-based, and not only compiler ones, reified generics.

So, how long is the way from current (abandoned) state to support .Net backend and is there any hope to bridge the technological differences between the platforms (in a layman terms)?

Thanks in advance for any enlightenment regarding the matter.

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

scala type system(scala IO)

sealed trait IO[A] {
    def flatMap[B](f: A => IO[B]): IO[B] =
      FlatMap(this, f)
    def map[B](f: A => B): IO[B] =
      flatMap(f andThen (Return(_)))
  }
  case class Return[A](a: A) extends IO[A]
  case class Suspend[A](resume: () => A) extends IO[A]
  case class FlatMap[A,B](sub: IO[A], k: A => IO[B]) extends IO[B]

 def printLine(s: String) :IO[Unit]=
    Suspend(() => Return(println(s)))

these codes are from the book functional programming in scala .
look the printLine function,why it return a type of IO[Unit]? should not is return type IO[IO[Unit]]?
Anybody can help me?

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

Typo on page 163 (Bindings) of the 2.9 Language Spec. There is no closing "}"

Subject line says it all (I hope)

Sorry if this is not the correct forum for this. If it isn't perhaps someone could enlighten me.

Cheers
Andre 

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

Scala Traits and JVM: Question about checkcast operation

Hello,
during a lecture the professor discussed how Scala inheritance works and
showed this example:

  trait T1 {}
  trait T2
{}
 
def foo(x : T1 with T2) = ???

I become curious: how this is implemented under the hood?

I tried to compile the following scala class:

  package traitsubtyping2

 
class C {
   
def foo(t: T1 with T2 with T3) = {
      t
.m1
      t
.m2
      t
.m3
      println
("C")
   
}
 
}



and then decompile it with javap -c C:

  Warning: Binary file C contains traitsubtyping2.C
 
Compiled from "C.scala"
 
public class traitsubtyping2.C {
   
public void foo(traitsubtyping2.T1);
     
Code:
         
0: aload_1
         
1: invokeinterface #16,  1 // InterfaceMethod traitsubtyping2/T1.m1:()V
         
6: aload_1
         
7: checkcast     #18       // class traitsubtyping2/T2
       
10: invokeinterface #21,  1 // InterfaceMethod traitsubtyping2/T2.m2:()V
       
15: aload_1
       
16: checkcast     #23       // class traitsubtyping2/T3
       
19: invokeinterface #26,  1 // InterfaceMethod traitsubtyping2/T3.m3:()V
       
24: getstatic     #32       // Field scala/Predef$.MODULE$:Lscala/Predef$;
       
27: ldc           #34       // String C
       
29: invokevirtual #38       // Method scala/Predef$.println:(Ljava/lang/Object;)V
       
32: return

   
public traitsubtyping2.C();
     
Code:
         
0: aload_0
         
1: invokespecial #45       // Method java/lang/Object."<init>":()V
         
4: return
 
}



An interesting discovery for me was that after compiling only the T1 is
used as the type of the method parameter. However, arguments for this
design decision seem to be clear: it does not require any new types to
be generated, and it is safe, because method arguments are already
checked by Scala compiler.

Nevertheless, one thing I could not understand: why checkcast is needed
before invokeinterface? If I understood it correctly, the
invokeinterface operation checks if method that is being called exists
and it does not mind what static type of that object is known to the JVM
(am I missing something?). Therefore, it should work in the same way without
checkcast?

I tried to delete checkcasts by using Java Bytecode Editor, and the printed
result was the same (method mX prints TX). Also, I tried to pass object,
which has a dynamic type T1 with T3 (I dropped T2), and with original
class C code, I got an exception:

  java.lang.ClassCastException: traitsubtyping2.TT cannot be cast to traitsubtyping2.T2

and with modified C code, I got an exception:

  java.lang.IncompatibleClassChangeError: Class traitsubtyping2.TT does not implement the requested interface traitsubtyping2.T2

Both error messages seem to be good enough, therefore, I do not think that
checkcast was needed to have a better error message.

So, the question that bugs me is: why checkcast is needed?

I uploaded all my experiments to github:
https://github.com/vakaras/scala-investigations.

For compiling I am using:
Scala IDE build of Eclipse SDK
3.0.4-2.11-20140723-2253-Typesafe
java version "1.7.0_65"
OpenJDK Runtime Environment (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.14.04.1)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

Kind regards,
Vytautas Astrauskas

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

Gmane