Shamy A | 16 May 00:45 2016
Picon

[scala-debate] Fwd: Islamic Info - Fwd: Us congress hearing of maan alsaan Money laundry قضية الكونغجرس لغسيل الأموال للمليادير معن الصانع







 

YouTube videos of

 

 U.S. Congress money laundering hearing


of

Saudi Billionaire  " Maan  Al sanea"

 with bank of America


and  The  owner of Saad Hospital and  Schools

 in the Eastern Province in Saudi Arabia

 

and the Chairman of the Board of Directors of Awal Bank  in Bahrain


With Arabic Subtitles


http://www.youtube.com/watch?v=mIBNnQvhU8s

 

 

موقع اليوتيوب الذي عرض جلسة استماع الكونجرس الأمريكي

 لمتابعة نشاطات غسل الأموال ونشاطات

 

السعودي معن عبدالواحد الصانع

 

مالك مستشفى  وشركة سعد  ومدارس سعد بالمنطقة الشرقية بالسعودية   ورئيس مجلس ادارة بنك اوال البحريني

 

مترجم باللغة العربية

 

http://www.youtube.com/watch?v=mIBNnQvhU8s

 















































































--
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.
Craig Tataryn | 26 Apr 22:18 2016
Picon
Gravatar

Need for `implicit` keyword on parameters

Is there a real need for specifying the `implicit` keyword in front of a parameter?  Couldn't the compiler -- after parameter binding fails to satisfy all values -- then flip to a strategy which finds suitable implicit values for the missing parameters? 

Regards,

Craig

--
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.
Jxtps | 25 Apr 20:17 2016
Picon

SIP suggestion: Add a This type to allow superclass method to return subclass type

https://tpolecat.github.io/2015/04/29/f-bounds.html has a great discussion about:

A common question on the #scala IRC channel is

I have a type hierarchy … how do I declare a supertype method that returns the “current” type?

The aesthetics are however a bit challenging - either you use an F-bounded type, Pet[A <: Pet[A]], which can "leak", or you use a TypeClass, which leads to a lot of boilerplate for each specific class.

Suggestion: add the concept of a "This" type, which denotes the type of the runtime instance, as known at compile time.

Example:

class StringBuilder {
  def append(s:String):This = {
    //...
    this
  }
}

trait Fancy {
  self: StringBuilder =>
  def fancy(s:String):This = {
    //...
    append(s)
  }
}

class FancyStringBuilder extends StringBuilder with Fancy {
}

val f = new FancyStringBuilder()
f.append("hello").fancy("world!")

where returning This allows the last chained call to happen - normally f.append() would return StringBuilder, which knows nothing about fancy(), and we'd get an error.


The compiler would only use & enforce the type as known at compile time, so this doesn't work:

val f:StringBuilder = new FancyStringBuilder()
f.append("hello").fancy("world!") // => compilation error, StringBuilder doesn't have fancy()


Conceptually, the calls would be very similar to:

val f = new FancyStringBuilder()
f.append("hello").asInstanceOf[FancyStringBuilder].fancy("world!")

Where the cast is guaranteed to succeed thanks to appen() returning This.


A method returning This has to either return this, return the result of another method that returns This, or be in a final class and return an instance of that class.


So in tpolecat's first example, you'd be allowed to do (changes highlighted):
trait Pet { def name: String def renamed(newName: String): This } final case class Fish(name: String, age: Int) extends Pet { def renamed(newName: String): This = copy(name = newName) }
While I'm only really envisioning the This type being used as a method return type, and being very strict in terms of what can be returned from such methods (i.e. pretty much only this), it might be both possible & desirable to expand the scope to include method parameters, and more lenient returns.

Allowing the This type to be used in e.g. collections, or getting passed along in type definitions (class Fish extends Pet[This]) sounds dangerous to me, but maybe that could be useful as well?

Thoughts?






--
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.
Simon Ochsenreither | 14 Apr 21:22 2016
Picon

RFC: Let's stop wasting the time of people who want to learn Scala?

Hi,

currently, people learning to program have to
  • download the JDK
  • install the JDK
  • setup $JAVA_HOME
  • download the Scala distribution
  • figure out that this is not what they want
  • download SBT
  • create a shell script/unzip SBT
  • put sbt on their $PATH
  • run sbt

before they are even compiling their first application.


Can we think about how we can get rid of all these steps and migrate to something that just works?


I wrote a short native application that does all of that in less than a minute while requiring zero interaction from the user: (time is with an existing ivy cache, not first-SBT-startup-time)

$ time ../sbs/target/debug/sbs XDG: "/home/soc/.cache/sbs/"
source url: "https://cdn.azul.com/zulu/bin/zulu8.13.0.5-jdk8.0.72-linux_x64.tar.gz"
target path: "openjdk-zulu/zulu8.13.0.5-jdk8.0.72-linux_x64.tar.gz"
source url: "https://repo.typesafe.com/typesafe/ivy-releases/org.scala-sbt/sbt-launch/0.13.11/sbt-launch.jar"
target path: "sbt-launcher/0.13.11/sbt-launch.jar"
...
[info] Set current project to threetenbp (in build file:/home/soc/Entwicklung/threetenbp/)
threetenbpRoot>
$ ../sbs/target/debug/sbs 4,00s user 0,54s system 26% cpu 17,186 total


Comments, opinions?

Thanks!

Bye,

Simon

--
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.
boris.hollas | 31 Mar 12:18 2016
Picon

Why does foldLeft not support operator syntax?

Scala supports operator syntax for methods of arity 1, so you can write
List(1,2,3) reduce (_+_)
while
List(1,2,3) foldLeft (0)(_+_)
fails with "error: Int(0) does not take parameters".

According to the style guide, you should use operator syntax for infix operators. However, the problem with dot-notation as explained in the style guide also applies to foldLeft:
List("a","b").foldLeft("") (_+_).toUpperCase

Also, why does foldLeft have curried parameters? This way, we can't write
List(1,2,3) foldLeft (0, _+_)

--
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.
joeteibel | 19 Feb 18:31 2016
Picon

7 reasons Scala is better than Java...

Wrote a piece on it over at developers.hp.com:

https://developers.hp.com/public/blog/7-reasons-scala-better-java-so-why-java-winning

Would love to hear your feedback!

--
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.
Tim Harper | 4 Feb 22:45 2016
Picon
Gravatar

Future.andThen should be deprecated

I think the behavior is tremendously surprising. That it returns a Future at all leads one to believe that "oh it's probably a future after the andThen completes".

I think `Future.onComplete` is wholly sufficient to modify side effecting code. Also, `Future.andThen` leads to further confusion because implies concatenation because of the `Function1.andThen` function.

I'd recommend that `Future.andThen` be deprecated. If people need to write side-effecting code, it's much clearer for them to use onComplete, which returns Unit and leaves little question as to it's affect on the value of the original future.

Tim

--
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.
Gareth Siret | 3 Feb 09:30 2016
Picon

Proposal to add collectors to Java Conversions so that a Java 8 stream can be collected to a Scala List.

Something like:


  def toList[T]() : Collector[T, ListBuffer[T], List[T]] = {

    val supplier = new Supplier[ListBuffer[T]] {
      override def get() : ListBuffer[T] = {
        new ListBuffer[T]
      }
    }

    val biConsumer = new BiConsumer[ListBuffer[T], T] {
      override def accept(buffer: ListBuffer[T], t : T): Unit = {
        buffer.append(t)
      }
    }

    val combiner = new BinaryOperator[ListBuffer[T]] {
      override def apply(t: ListBuffer[T], u: ListBuffer[T]) : ListBuffer[T] = {
        t.appendAll(u)
        t
      }
    }

    val finisher = new java.util.function.Function[ListBuffer[T], List[T]] {
      override def apply(t : ListBuffer[T]) : List[T] = {
        t.toList
      }
    }
    Collector.of(supplier, biConsumer, combiner, finisher)
  }

Does anyone have any thoughts on whether this is a good plan?

--
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.
Petr Novak | 29 Jan 11:11 2016
Picon

Why trait "extends" class instead of "with" when class extends only a trait(s)?

Hi,
I'm used to understand inheritance like "what it is" (or behave as) and mixins as "what is has". Anytime I see things like "class Person extends Logging" it confuses me. Why we can't write "class Person with Logging"? Is there any reason for it, like Java interop, or it has been overseen?

The only solution I'm aware of to adhere to formalism would be to write "class Person extends AnyRef with Logging":( (I haven't actually try it though)

Many thanks.
Petr

--
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.
Koert Kuipers | 26 Jan 17:47 2016

functions pretty print

scala> val f1 = { (x: String) => x + "!" }
f1: String => String = <function1>

scala> println(f1)
<function1>


wouldn't it be nice if functions (Function1, Function2, etc.) print out the actual code? is this something that can be done with macros maybe?
the current toString is not very helpful or informative.

--
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.
Simon Ochsenreither | 21 Jan 15:46 2016
Picon

FAQ: Why does Scala use "i: Int" syntax instead of "Int i"?

Proposed text:
========================================

While both syntactic approaches seem to be roughly equivalent on a cursory look, the advantages become clear when investigating how the syntax scales to larger examples.

Instead of i: Int and Int i, let's have a look at a generic method definition and its usage

class Bar[T](t: T) {
  def foo[S, T](s: S): T = ???; foo[Int, String](42)
}


to discover some desirable properties:
  1. consistency in declarations like classes, methods, ...:
    Regardless of whether we define a class or a method, the ordering is the same: keyword – name – type parameters – value parameters – body
  2. consistency between declaration and usage:
    the invocation of foo mirrors the declaration of foo – you just supply an argument to every parameter
  3. declaration before use: the type variable name is introduced before it is used.
  4. clear nesting/scoping: It should be obvious to the reader to which type variable a type parameters refers to.
If we check alternative syntactic approaches against these properties, we will see that all of them fail at least one of these properties:

class Bar[T](T t) { – or – class [T] Bar(T t) {
  [S, T] T foo(S s) = ???  // fails (1) and (2)
}

class Bar[T](T t) {
  T foo[S, T](S s) = ???  // fails (3) and (4): T is used before it is defined ... or does foo's return type refer to the T of the class?
}

Scala's approach provides consistency, reduces the mental complexity and let's users treat type parameters like the value parameters they already know: A method can have zero or more value parameter lists and zero or one type parameter lists.

========================================
Opinions? (I know that the wording around type variable, type parameter is not quite right ... need to fix that.)

--
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