Backport accepted SIPs to ease cross compilation

Dear all,

This may come a little late (but hopefully not too late):

Would it be possible to backport certain / all SIPs which have been accepted for 2.10 to 2.9 to ease
cross compilation? (like SIP-14 already has to 2.9.3)

If someone uses, say language imports and implicit classes in a 2.10 project and wants to cross
compile and release for 2.9, one would have to change back the code to full 2.9 compatibility to
make this possible (drop all implicit classes and use the old class + implicit def, drop all
language imports) or -- even worse -- create a separate branch with the alternate code (aka
maintenance hell).

For this reason I'm humbly asking for backports for the features introduced in 2.10 to allow the
usage of these features in projects while still having no maintenance problems compiling for older
versions.

I have also already searched for and located an issue [SI-6694][1] which was unfortunately closed
prematurely without much discussion.

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

--

-- 

Beste Grüße / Best Regards
Christian Krause aka wookietreiber

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

EGAL WIE DICHT DU BIST, GOETHE WAR DICHTER.

Study on security and safety in functional programming languages

Hi all,

For those of you that understand french, an interesting study on security and safety in functional
programming languages was published by ANSSI (French national agency for information security) [1].
The study presents 7 functional languages: Scala, OCaml, F#, Haskell, LISP, Scheme and Erlang and
analyses 3 of them: Scala, OCaml and F#

For Scala, the analysis focuses on two aspects:
 - the development environment and its impact on security
 - the constructs and their impact on security and safety

Of course, this report for Scala relates to a previous study on the Java platform [2], which is not repeated here.

The evaluated version is Scala in its version 2.8.1 on the Oracle HotSpot JVM in its version 1.6.25, which is
quite old and some points raised are no relevant anymore (e.g. catching `Throwable`). Many warnings and
advices are actually good practices already given by the coding guidelines. Some other points are only
relevant when dealing with applications in which security is critical (well, that's the goal of such a
report, after all...)

The rest of the study that concerns other languages (mainly OCaml) can be interesting also to see how it
differs from Scala. The state of the art of programming language [3] is also interesting to compare some
properties with other languages, in particular the table on page 55.

Regards,

Lucas

[1] http://www.ssi.gouv.fr/fr/anssi/publications/publications-scientifiques/autres-publications/lafosec-securite-et-langages-fonctionnels.html
[2] http://www.ssi.gouv.fr/fr/anssi/publications/publications-scientifiques/autres-publications/securite-et-langage-java.html
[3] http://www.ssi.gouv.fr/IMG/pdf/LaFoSec_-_Etat_des_lieux_des_langages_fonctionnels.pdf

OutOfMemoryError considered fatal?

Mailing list reminder: Scala-language

Welcome to the "Scala-language" 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-language" mailing list:

This list is the main forum for discussions and news about the
Scala language. Questions about programming in Scala, especially
by beginners, should preferably go to the "scala-user" list
instead: please post there if you would like to discuss your
code snippets or need assistance. Questions about Scala tools
should go to "scala-tools".

Questions about the Scala IDE for Eclipse should go to 
http://groups.google.com/group/scala-ide-user.

Threads that become too long, and are unlikely to be of general
interest, should eventually be moved to "scala-debate".

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

Other information:

There are several Scala lists devoted to individual topics (and
more may be created in the future). For the full list, please
see: http://www.scala-lang.org/node/199

Try to avoid cross-posting whenever possible. If you can, select
the list that is closer to your topic and post in that list only.
In any case, never cross-post replies.

If you ever want to unsubscribe from this list, just visit this
page: http://groups.google.com/group/scala-language/subscribe
or send an email to scala-language+unsubscribe <at> googlegroups.com

Thank you!
The Scala Team

--

-- 
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/groups/opt_out.

Re: Scala Code Coverage - for Functional Testing

parameter inference

I accidentally noticed that on 2.10.2.v20130425-053916-403ba8938f the 
following compiles:

   class A { def a(i: Int) = i }
   class B extends A { override def a(i) = i } // no type parameter on i

While I heard of such a potential change some time ago, I can't find the 
commit where it is finally merged.

Anyone here who can point me to it?

--

-- 
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/groups/opt_out.

compiler message not clear with FiniteDuration.times

Unary type view

Hi,

I have problems understanding Scala's type system. Why does the
following code not compile in the line 'val z = ...'?

trait Unary[U[_], A]

case class A[T](t: T)
case class B[I[_], A](i: I[A]) extends Unary[({type O[X] = B[I, X]})#O, A]

def unary[MA <: Unary[U, A], U[_], A](ma: MA with Unary[U, A]): U[A] =
ma.asInstanceOf[U[A]]

val a = A(5)
val b = B(a)
val z = unary(b)

I get the error message: Multiple markers at this line
    - type mismatch; found : B[A(in method
monadicAndMonadicStackSelection),Int] required: MA with
     Unary[U,A(in method unary)]
    - no type parameters for method unary: (ma: MA with Unary[U,A])U[A]
exist so that it can be applied to
     arguments (B[A,Int]) --- because --- argument expression's type is
not compatible with formal parameter type;
     found : B[A,Int] required: ?MA with Unary[?U,?A]

I don't understand why Scala cannot match the types. B is of type Unary.

I expect the type of z to be ({type O[X] = B[A, X})#O[Int]. I know that
I can achieve that using scalaz's Unapply type class, but I don't
understand why my solution should not work either.

Any thoughts?

-- 
Best Regards

Ka Ter

--

-- 
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/groups/opt_out.

Mining for granularity beyond AnyVal

[Macros] Passing context instance reference to another class

Existentials and method types

I was surprised and delighted by a bug a coworker found today, which hinged on my assuming that surely value
types can never contain non-value types. Here's a simplified version:

import scala.reflect.runtime.universe._

class A {
  object B
}
class C {
  val a = new A
  val b = a.B
}

object Test extends App {
  val cType = typeOf[C]
  val bType = cType.member("b": TermName).typeSignatureIn(cType)
  bType match {
    case NullaryMethodType(_) =>
      println("That's what I thought.")
    case ExistentialType(_, NullaryMethodType(_)) =>
      println("Huh???")
  }
}

Is this a bug, or is it reasonable to expect that ExistentialType, a value type, can contain a
NullaryMethodType, a non-value type?

(please forgive me my corporate legal disclaimer)

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

This message is intended exclusively for the individual(s) or entity to
which it is addressed. It may contain information that is proprietary, 
privileged or confidential or otherwise legally exempt from disclosure. 
If you are not the named addressee, you are not authorized to read, 
print, retain, copy or disseminate this message or any part of it. 
If you have received this message in error, please notify the sender 
immediately by e-mail and delete all copies of the message.

--

-- 
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/groups/opt_out.