Guanpeng Xu | 21 May 08:25 2016
Picon

On inference of existential types

Dear group,

Suppose I have a Java class Q defined as this:

public class Q<T> {

    public Q() {}
    public Q(Q<T> q) {}

    public static <T> Q<T> f(Q<? extends T>[] qs) {
        throw new UnsupportedOperationException();
    }

    public static <T> Q<T> g(Q<? extends Q<? extends T>> q) {
        throw new UnsupportedOperationException();
    }
}

Now, the following Scala program cannot be compiled:

object C {

    val qs: Array[Q[_ <: Int]] = Array.fill(1)(new Q())
    val a = Q.f(qs)

    val q: Q[_ <: Q[_ <: Int]] = new Q(new Q())
    val b = Q.g(q)
}

The errors are

[error] Q.scala:6: no type parameters for method f: (x$1: Array[rxtest.Q[_ <: T]])rxtest.Q[T] exist so that it can be applied to arguments (Array[rxtest.Q[_ <: Int]])
[error]  --- because ---
[error] argument expression's type is not compatible with formal parameter type;
[error]  found   : Array[rxtest.Q[_ <: Int]]
[error]  required: Array[rxtest.Q[_ <: ?T]]
[error]     val a = Q.f(qs)
[error]               ^
[error] Q.scala:6: type mismatch;
[error]  found   : Array[rxtest.Q[_ <: Int]]
[error]  required: Array[rxtest.Q[_ <: T]]
[error]     val a = Q.f(qs)
[error]                 ^
[error] Q.scala:9: no type parameters for method g: (x$1: rxtest.Q[_ <: rxtest.Q[_ <: T]])rxtest.Q[T] exist so that it can be applied to arguments (rxtest.Q[_$2])
[error]  --- because ---
[error] argument expression's type is not compatible with formal parameter type;
[error]  found   : rxtest.Q[_$2] where type _$2 <: rxtest.Q[_ <: Int]
[error]  required: rxtest.Q[_ <: rxtest.Q[_ <: ?T]]
[error]     val b = Q.g(q)
[error]               ^
[error] Q.scala:9: type mismatch;
[error]  found   : rxtest.Q[_$2] where type _$2 <: rxtest.Q[_ <: Int]
[error]  required: rxtest.Q[_ <: rxtest.Q[_ <: T]]
[error]     val b = Q.g(q)
[error]                 ^
[error] four errors found

I expected T in the two calls to be inferred as Int, but something prevented that.  Is this due to a bad design of the Java program, or some limitation of the type inferer of Scala?

(The example above is simplified from the real world design of RxJava.  I asked a question on StackOverflow.  My intention was to understand the Scala language and I was not satisfied with the answer there.)

Best regards,
Guanpeng Xu

--
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.
Marc Arndt | 17 Apr 12:27 2016
Picon

Different behaviour from Option map in scala compared to Optional map in java

Hello,
while programming with java 8 and scala I discovered that both seem to have a different behaviour with the method map in the classes Option in scala and Optional in java.
In scala the method map in Option is implemented as followed:
  <at> inline final def map[B](f: A => B): Option[B] =
    if (isEmpty) None else Some(f(this.get))
This method requires, that f doesn't return null.

In java the method map in Optional is implemented as followed:
    public<U> Optional<U> map(Function<? super T, ? extends U> mapper) {
        Objects.requireNonNull(mapper);
        if (!isPresent())
            return empty();
        else {
            return Optional.ofNullable(mapper.apply(value));
        }
    }
This method does not require, that the given method returns a value not null, it is also accepted to return null.

I'm not sure if this behaviour is intended.

Many Greetings
Marc

--
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.
Piotr Tarsa | 13 Apr 13:02 2016
Picon

Reworking import statements (proposal)

Hi,

As of now relative imports (ie importing from something already imported) look exactly the same as absolute ones (ie where we're importing using full paths), except when explicitly starting from _root_. That is both confusing (where I have relative or absolute import? it's not immediately obvious) and ugly (the _root_ prefix is ugly).

My proposal is to change import statements semantics to make things obvious:

Current state:
import _root_.outer.inner.Member - for absolute imports (usually used when there are name clashes)
import outer.inner.Member - for absolute imports (usually used when there are no name clashes)
import inner.Member - for relative imports
import parameter.member - for importing from parameters

Proposal for next Scala version:
import _root_.outer.inner.Member - deprecate _root_ prefix
import outer.inner.Member - leave as it is
import inner.Member - deprecate this form of relative imports
import _.inner.Member - introduce this syntax for relative imports
import parameter.member - leave as it is

And a version after that:
import _root_.outer.inner.Member - drop support for _root_prefix
import outer.inner.Member - keep it
import inner.Member - drop support for this form of relative imports
import _.inner.Member - keep it
import parameter.member - keep it

What do you think about it?

Regards,
Piotr Tarsa

--
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.
John Michael Lafayette | 11 Apr 05:05 2016
Picon

Scala Macro "context.internal.enclosingOwner" - Getting File And Line #

I was recently playing around with this library - https://github.com/lihaoyi/sourcecode

It lets me output the file location and line number like this: sourcecode.DebugFull.main Foo [arg]: 123

It seems to use this feature, c.emclosingPosition.source . scala.reflect.macros.Enclosures

I want to use it to improve my library, https://github.com/JohnReedLOL/scala-trace-debug

Instead of using Thread.currentThread.getStackTrace() to get the current position in the source code, I want to use "context.internal.enclosingOwner".

The problem with this is that for "context.internal.emclosingPosition.source" to work with stack trace highlighting in the IDE, the formatting must match the formatting produced by a real stack trace. lihaoyi's library does not do this, but if it did, the performance would be better than a regular stack trace and it could be used in place of a one line stack trace.

Is there any way to make macro source code position look like a real stack trace line so that stack trace highlighting would work?

Example: bootstrap.liftweb.Boot.<init>(Boot.scala:25)

--
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.
Rich Oliver | 7 Apr 14:45 2016
Picon

Seq :+ repeat parameter

I have created the following code and it seems to compile and run correctly:

val scaleButs = Seq(CanvButton("+", () => { scale = (scale * 1.5).min(scaleMax); repaintMap() }),
      CanvButton("-", () => { scale = (scale / 1.5).max(scaleMin); repaintMap() }))
   val mapButs = scaleButs :+ (     
      CanvButton("<=", () => { mapFocus = mapFocus.subX(moveInc); repaintMap() }),
      CanvButton("=>", () => { mapFocus = mapFocus.addX(moveInc); repaintMap() }),
      CanvButton("Up", () => { mapFocus = mapFocus.addY(moveInc); repaintMap() }),
      CanvButton("down", () => { mapFocus = mapFocus.subY(moveInc); repaintMap() })
   )

But in the API documentation the :+ doesn't have a repeat parameter. I've looked in SeqLike.scala https://github.com/scala/scala/blob/v2.11.8/src/library/scala/collection/SeqLike.scala#L1 and I can't see any repeat parameter for the :+ method there either.

--
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.
Philippe Suter | 5 Apr 20:14 2016
Picon
Gravatar

AnyVal makes private case class constructor public

I'm wondering if the observed behavior is intentional; in the attached file, I expect the three class construction calls to fail, but only the ones commented out do.

It seems that having a case class extends AnyVal renders its constructor public.

Maybe a special case of https://github.com/scala/scala/pull/2236 ?

Tested on Scala 2.11.8.

Best regards,
PS

--
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.
Attachment (Example.scala): application/octet-stream, 487 bytes
Samuele Pretini | 30 Mar 16:04 2016
Picon

Meaning of Element methods

Hi at all,

I'm new student of Scala.

During some test that I'm doing, I have seen the class scala.collection.IndexedSeqLike.Elements

In this class there is a method: aggregate

The signature of the method is the question: 
def aggregate[B](z: ⇒ B)(seqop: (BA) ⇒ Bcombop: (BB) ⇒ B)B

  1. What's mean of  z: => B ?
  2. What's mean of the 2 parenthesis: (z: ⇒ B)(seqop: (BA) ⇒ Bcombop: (BB) ⇒ B)
Can someone of us to explain to me?

Thanks a lot. :-)

--
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.
Nicola Contu | 29 Mar 14:53 2016
Picon

Open Source Forum in Scala

Hey There,
Is there any open source forum written in Scala?

Thanks a lot,
Nicola


--
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.
Christopher Lee | 27 Mar 19:11 2016
Picon
Gravatar

Possible inconsistent error for "+=" shorthand while using immutable set

Hello,

I'm just starting to learn Scala, and I came across the following example in the "Programming in Scala" book.

var jetSet = Set("Boeing", "Airbus")
jetSet
+= "Lear"
println
(jetSet.contains("Cessna"))

One of the lesson points is that the default Set is immutable. So, I wanted to test that line 2 in the above actually reassigns a new immutable set with the element added to the jetSet variable.

I then changed the var to a val and expected to see a reassignment error. Instead I got the below error.

immutableSet.scala:2: error: value += is not a member of scala.collection.immutable.Set[String]
jetSet
+= "Lear"
       
^

While the error message is true, it's strange that the compiler didn't complain about "+=" before. "+=" is shorthand for `jetSet = jetSet + "Lear"`, so I would expect to see a reassignment error.

E.g. If I were to run the program with the long form, I get the expected error message.

val jetSet = Set("Boeing", "Airbus")
jetSet
= jetSet + "Lear"
println
(jetSet.contains("Cessna"))

immutableSet.scala:2: error: reassignment to val
jetSet
= jetSet + "Lear"
       
^

Am I missing something (very likely since I'm a newb) or does this seem inconsistent?

Thanks for reading!
Chris

--
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.
P. Oscar Boykin | 25 Mar 05:11 2016
Picon
Gravatar

any static state in scala.tools.nsc.Global?

The name scares me that it might be squirreling away some state, but if I were to instantiate this:

https://github.com/scala/scala/blob/2.11.x/src/compiler/scala/tools/nsc/Global.scala

and pass it the same options the command line wound have in scalac, can I expect that all state is reset on each new instantiation?

What I am really trying to do is be able to get the jit to run on the code, leave a compiler resident and have it compile without one run changing the state of the next (for the bazel build system: https://github.com/bazelbuild/rules_scala ). Bazel's model makes zinc integration a challenge (maybe doable, but this is a first step anyway).

Any feedback on what I am trying to do would be great.

--
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.
Denys Shabalin | 24 Mar 11:46 2016
Picon
Gravatar

Re: GSOC 2016: FastParse library

A bit more info on the project I had in mind:

https://github.com/scala/scala-lang/pull/424

Potential contributors: you can still apply for this one. 

Cheers,
Denys

On Tuesday, March 22, 2016 at 11:37:13 AM UTC+1, Haoyi Li wrote:
Given we already have the Scalaparse XML parser, I doubt an XML parser is a summer's worth of work, unless you want to hook it up with a downstream AST and API and other such tools. I'd estimate it'd take 1-2 weeks to rip out the Scalaparse XML parser and feed through enough XML as a test suite to be pretty confident of it's correctness.

On Tue, Mar 22, 2016 at 5:31 PM, Denys Shabalin <den.sh... <at> gmail.com> wrote:
Another thing that would be great to have is an XML parser. 
I'd be willing to mentor if anyone wants to work on that. 

Cheers,
Denys

On Tuesday, March 15, 2016 at 9:14:24 PM UTC+1, Haoyi Li wrote:
Math expressions would be too simple. I'd be fine with a CSS parser

On Wed, Mar 16, 2016 at 3:39 AM, Simon Ochsenreither <simon.och... <at> gmail.com> wrote:
Hey Haoyi, I think CSS would be a lot simpler. Not sure if your choice of Markdown was intentional, but Markdown knocks it out of the ballpark in terms of difficulty. Personally, I would rather parse C++ than Markdown. It's really really ugly to parse, and because it's so different from programming languages it's hard to find help if one is stuck.

--
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-languag... <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-languag... <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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