Puneet Khanduri | 14 Apr 19:01 2014
Picon

Trait Inference

Say you have an old library with :

class CanNotRefactor {
  def plus(other: CanNotRefactor): CanNotRefactor
}

And you have some new code :

trait Addable[+A] {
  def plus(other: A): A
}

It would be nice if scala could infer traits of a given class based on what methods are implemented and what traits are explicitly defined.

In this example I can not go back and rewrite CanNotRefactor to explicitly say that it extends the Addable trait but it implements "plus" and meets the requirements of the trait. It would be nice if I could leverage everything written for Addables and be able to apply to CanNotRefactors.

 

--
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.
Kieran Douglas | 13 Apr 23:08 2014
Picon

Scala as a teaching language

Hi,
I'm a final year computer science student at the University of York and I was wondering if some of you could help me out.

I've been looking for some literature on Scala being used as a teaching language. Specifically I'm looking for Scala being used to teach interpreters, parsers and to define new programming languages.
Basically I am looking at the feasibility of Scala for the book: Essentials of programming languages. (http://en.wikipedia.org/wiki/Essentials_of_Programming_Languages)

Has anyone seen something like this about or can give me some pointers on where to look?

Thanks in advance,
Kieran

--
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.
Erik Bruchez | 4 Apr 23:40 2014
Picon

Re: GSOC Project: Bringing Scala 2.7 Era XML into the Modern World

At the same time the html 5 spec discourages using the xhtml serialization form. This leads to the question what xml literals are used for. Most arguments for xml literals seem to lean heavily on their usefulness of writing literal xhtml, a discouraged practice. That leaves "general purpose" xml. I'm not quite sure this is used much, and I'm not quite sure it leads to a sufficiently large improvement in expressiveness to make a second parsing mode of the language defensible. Are there any examples of xml mode used in the wild that are agreed to be good use if the feature? I'd love to be proven wrong, but i'm not seeing it.


You are mixing two separate things:

- the syntax used within Scala
- the serialization as HTML vs. XHTML

You can certainly use XML literals to produce plain HTML (as opposed to XHTML). This only means that the syntax, within Scala, must be well-formed XML as opposed to HTML, but in practice this only means that:

- you must quote attributes
- you must close all tags

The result of this is a tree. That tree can be serialized to plain XML, XHTML, HTML, or in fact anything you like - XSLT for example has separated serialization from the rest for a very long time, see:

    http://www.w3.org/TR/xslt-xquery-serialization/

It's relatively easy to serialize an XML data model representing HTML to actual HTML.

The bottom line is that using XML literals in Scala doesn't force you to produce an XHTML serialization. They are perfectly adapted to produce HTML.

Now there could be native HTML support as well, why not, e.g.:

    val myHTML = html"""<body>Hello<br> $name!</body>"""

-Erik

--
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.
Nick Stanchenko | 4 Apr 18:42 2014
Picon

Some thoughts on string interpolation

Hi,

I really like string interpolation and the trend of it becoming a powerful way of hosting pretty much any language (scala itself, xml, markdown, ...). To me there is just a couple of small nitpicks that I would like to share.

First, unlike imported identifiers, interpolators can’t be renamed. Right now we have just a few of them, but imagine a hypothetical situation where you have two interpolators with the same name, and you need to use both. I know one can create several scopes individually importing the desired RichStringContext, but overall the feature seems to lag behind the flexibility of the module/namespacing aspect of Scala.

Second, consider x"""
  ...
"""
In my opinion, """ makes for an ugly closing marker! Also there is a lot of unwanted whitespacing coming from the eye-pleasing new-lines and indentation. For strings, we have .stripMargin, but once this compiles to something different than a string (e.g. https://github.com/stanch/scalatags-md), this ability is lost. Or you have to force the users to always put “|”s in the string.

I am not going to suggest a solution, but maybe there are thoughts on this in the community? Perhaps as a side-note, I was passing by a Nemerle page today (http://nemerle.org/About#ID0E6G), and it has a dedicated quotation operator, which may or may not help.

Nick

--
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.
Nick Stanchenko | 3 Apr 12:07 2014
Picon

How (not to) name things

As we all know, naming things is one of the hardest problems in CS. In this regard, http://www.urbandictionary.com/ has recently proved to be a fruitful source of both inspiration and sincere discouragement. My modest attempt at combining “macros” and “android” in one word resulted in what the site deems to be “a noodle that has been lying on the floor for a number of weeks”! [1] Interestingly enough, UrbanDictionary holds its own opinions even about scala (“It's a bit like Java, except with all the syntactical cruft removed, closures and first-class functions added, and an awesome collections library.” [2]) and macros themselves (“Ok the people here obviously don't know what a macro is. A macro is a funny picture with a caption in it.” [3]). A recent commit discussion revealed Eugene’s [4] clever neologism to be in fact an old artifact of post-Myspace era [5]. As a final exercise, try to guess the meaning of the word ‘akka‘ in the following sentence: “she was going akka outside the club last night” [6].

What am I getting at? I don’t know! This site is weird. Don’t ever search for your projects there. Or do, if you fancy renaming them. Perhaps in the future <at> Som-Snytt could include some of these into his cracking SO reports.
Full disclosure: I have never heard any of the meanings linked above; I do not stand behind any of the respective UrbanDictionary entries.

Nick

[1] http://www.urbandictionary.com/define.php?term=macroid
[2] http://www.urbandictionary.com/define.php?term=scala
[3] http://www.urbandictionary.com/define.php?term=macros
[4] http://www.urbandictionary.com/define.php?term=eugene
[5] http://www.urbandictionary.com/define.php?term=mygration
[6] http://www.urbandictionary.com/define.php?term=akka

--
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.
Jason Zaugg | 2 Apr 09:16 2014
Picon

Re: Play/Future/Monad/inference/macro annotations/quasiquotes/slick noob question, help thanks

On Wed, Apr 2, 2014 at 9:06 AM, Alexandru Nedelcu <alex <at> bionicspirit.com> wrote:

On Wed, Apr 2, 2014 at 8:05 AM, Som Snytt <som.snytt <at> gmail.com> wrote:

I think it's a problem with ForkJoinPool because my app just hangs.  Can anybody tell me how ForkJoinPool works?  I think it must be a bug because my app is pretty simple.

Without details, nobody can answer that. Do a thread-dump - it might give you an idea of where the deadlock is.

Somebody commented that blocking is evil.  Is that true?  Like Dark Side evil or the lesser of two?  Anyway, it's possible something is blocking, because I'm using that Twitter util to make the flapping bird send out tweets of its progress.  Would that be blocking?

It’s not that blocking is evil, but rather that it is very, very error-prone and you have to know exactly what you’re doing. When you’re blocking a thread, the general rule of thumb is to know exactly what thread-pool is used and how it is configured. Also, mixing blocking operations that wait for operations on the same thread-pool leads to really nasty deadlocks due to thread-starvation.

Take this sample:

implicit val ec = ExecutionContext.fromExecutor(Executors.newFixedThreadPool(1)) def asyncSum(a: Int, b: Int): Future[Int] = Future { val r1 = Await.result(longRunningQuery(1.second, a), Duration.Inf) val r2 = Await.result(longRunningQuery(1.second, b), Duration.Inf) r1 + r2 }

If longRunningQuery is scheduled to run on the same thread-pool, then that’s a guaranteed dead-lock, regardless of the size of the thread-pool, as long as the thread-pool has an upper bound and is unaware of Scala’s BlockContext. Which is precisely why I’m saying that when blocking, you really need to know what you’re doing ;-)

Ideally, I want to use macro annotations.  Would that work?  I tried using quasiquotes but I just got

If you’re a rookie, just don’t go there. Macros are experimental. Wait at least for Scala 2.11 and for better documentation.

Unfortunately, I'm still having problems with Futures and scala-async. Those are two different things, correct?  I hope for an answer that explains the Klangism.

Scala-Async is built on top of Futures. Any function that uses async/await can be transformed into a bunch of flatMap and map calls, with Scala-Async being just syntactic sugar over Futures.

Firstly, I couldn't use await() in a try/catch block; well fine, that was expected I guess; so I converted the function to return a Future[Try[T]] instead, which of course under normal circumstances is redundant as Future[T] already contains any exceptions but allowed me to call isSuccess on the return value instead of try/catch.

To me that was a surprise, not expected at all. I guess the issue is that it’s hard for the compiler to jump in and out of a try block, while preserving the catch / finally semantics. I do hope this limitation will go away, because C# can do await inside the try block (although it still cannot do await inside a catch block).

I then went on to try to implement the looping logic. a nested recursive iter() was out of question (again, as expected) because await() cannot be used in nested functions.

Using it in nested functions or closures is problematic, because the compiler cannot know if the execution of that function is meant to be synchronous or asynchronous, in which case the await would escape the async block. Anyway, without listing the actual problem you’re trying to solve and what you tried to do, I cannot help you much.

So my question is, given (at least) these 3 limitations the last of which I'd say is extremely limiting, to the extent of at least seemingly rendering scala-async useless for any real life code apart from carefully chosen examples such as await(x) + await(y), what are the currently known useful real life applications of this library?

You’re better off starting to learn more about Futures and their usage without Scala-Async. Scala-Async is the kind of leaky abstraction - useful for beginners, useful to clean up a callback hell, but to use it efficiently your mental model needs to be in sync with how Future works. As I’ve said, the compiler basically takes that async block and transforms it into an expression that uses the various combinators and utilities on the Future interface. If you cannot do that transformation by yourself, then there’s a high probability that the compiler won’t be able to do it either.

On the other hand, I’ve used it successfully in actual production and I love it.

Glad you've found it useful, Alexandru!

Just so you know, I believe that Som lives in a a little known corner of the globe where it is still 1. April where parody is the sincerest form of flattery.

Not-a-joke: try/catch/finally support for scala-async is on my todo list. It has proved a bit tricky to implement, but thats mostly just down to a scarcity of time.

-jason

--
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.
virtualeyes | 30 Mar 09:42 2014
Picon

GSOC Project: Bringing Scala 2.7 Era XML into the Modern World

I noticed that Scala XML has been broken out from the compiler into a separate library in Scala 2.11.

I also noticed in the commits a message saying something along the lines of, "alternative implementations appreciated!", which I take to mean, "this library is in rough shape, we're going to punt on doing anything about it for the forseeable future".

So, given that some of us absolutely love XML, particularly support for XML literals which make for near-ideal XHTML markup generation, how about a GSOC project that kicks off Scala XML a la 2.11 and beyond? i.e. Scala XML in the modern world.

Anti-XML at one time looked promising and is now abandoned/dead. There are other implementations as well that focus on various sub functionality (like querying), but none that take on the whole enchillada as Anti-XML was on target to do.

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.
Tim Pigden | 29 Mar 21:30 2014

Re: An appeal (use of brackets)

>>  but it seems to me that Scala is a new language and has yet to be widely adopted,
Not so new. But most scala adopters are coming from java (sorry this is an unsubstantiated non statistic, but I believe it to be true) so the argument would be to minimise perception of the shift. Having a new {} style would accentuate it



On 29 March 2014 20:05, Richard Prosser <ebizbytes <at> gmail.com> wrote:

On 29 March 2014 19:33, Tim Pigden <tim.pigden <at> optrak.com> wrote:
What I realised was that regardless of whether it was better or not, it was not what everybody else was doing. There is a massive advantage in using the same conventions as everybody else. For at least 2 reasons:
1. the other guys are used to the other convention and they will read your code faster if you follow standard models.
2. If you've got 2 people working on the same code base, there is a naughty tendency on the part of whoever has been making major edits to "tidy up" - and this leads to spurious version control system diff problems. 

I am well aware of the argument that one should stick to conventions but it seems to me that Scala is a new language and has yet to be widely adopted, so I hoped to influence the design before it is too late to do so.


Richard




--
Tim Pigden
Optrak Distribution Software Limited
+44 (0)1992 517100
http://www.linkedin.com/in/timpigden
http://optrak.com
Optrak Distribution Software Ltd is a limited company registered in England and Wales.
Company Registration No. 2327613 Registered Offices: Suite 6,The Maltings, Hoe Lane, Ware, SG12 9LR England 
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Optrak Distribution Software Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.

--
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.
Richard Prosser | 29 Mar 18:51 2014
Picon

An appeal (use of brackets)

Sorry if this issue has been addressed before; I did search but found little of relevance.

Also I am new to Scala, having used Python and wanting some features that it does not possess. One thing I really like about Python however is the clean syntax and the ease of use.

So, why perpetuate the awful way of bracketing code? I refer to this kind of practice in "pseudo-code" style:

function {

blah ...
blah ...
}

rather than:

function
{

blah ...
blah ...
}


In other words, I strongly believe that any brackets used should line up in the same column! IMO that makes the text easier to read and the logic easier to follow.

Python suffers a similar fate with Docstrings:

def fn():
""" Some description in the first line
blah ...
"""

rather than:
def fn():
"""
Some description in the second line

blah ...
"""

I hope that Scala does not fall into the same trap with its equivalent of documentation, if there is one.

Please consider the psychological aspects of programming when designing a language. Few people do and the results are often awkward, to say the least.


Thanks ...

Richard

--
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.
Alexander Berger | 26 Mar 17:12 2014
Picon

Generating of secondary constructors using quasiquotes seems to be broken

Hi 

using Scala 2.11.0-RC3 with the macro paradise plugin (2.0.0-SNAPSHOT).

If I create a secondary constructor using quasiquotes in a macro like this:

val secondary = q"def this() = this(1)"

I get an compiler error when the macro is applied (see stack trace below):

showRaw(secondary), reveals that the above quasiquote resulted in the following Tree:

DefDef(Modifiers(), termNames.CONSTRUCTOR, List(), List(List()), TypeTree(), Apply(Ident(termNames.CONSTRUCTOR), List(Literal(Constant(0)))))

If I create the secondary constructor manually as a Tree like this (by explicitly wrapping the call to the primary constructor in a Block) then everything works:

val secondary = DefDef(Modifiers(), termNames.CONSTRUCTOR, List(), List(List()), TypeTree(), Block(List(), Apply(Ident(termNames.CONSTRUCTOR), List(Literal(Constant(0))))))

So now I'am wondering. Am I doing something wrong or is this a bug in quasiquotes or the compiler.

scala.MatchError: MyID4.this.<init>(0) (of class scala.reflect.internal.Trees$Apply)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer$$anonfun$6$$anonfun$apply$5.apply(UnCurry.scala:436)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer$$anonfun$6$$anonfun$apply$5.apply(UnCurry.scala:435)
        at scala.reflect.api.Trees$Transformer.atOwner(Trees.scala:2600)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.atOwner(TypingTransformers.scala:30)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.mainTransform(UnCurry.scala:433)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.transform(UnCurry.scala:94)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.transform(UnCurry.scala:65)
        at scala.reflect.api.Trees$Transformer$$anonfun$transformStats$1.apply(Trees.scala:2589)
        at scala.reflect.api.Trees$Transformer$$anonfun$transformStats$1.apply(Trees.scala:2587)
        at scala.collection.immutable.List.loop$1(List.scala:172)
        at scala.collection.immutable.List.mapConserve(List.scala:188)
        at scala.reflect.api.Trees$Transformer.transformStats(Trees.scala:2587)
        at scala.reflect.internal.Trees$class.itransform(Trees.scala:1397)
        at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16)
        at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16)
        at scala.reflect.api.Trees$Transformer.transform(Trees.scala:2555)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.scala$tools$nsc$transform$TypingTransformers$TypingTransformer$$super$transform(TypingTransformers.scala:40)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer$$anonfun$transform$1.apply(TypingTransformers.scala:40)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer$$anonfun$transform$1.apply(TypingTransformers.scala:40)
        at scala.reflect.api.Trees$Transformer.atOwner(Trees.scala:2600)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.atOwner(TypingTransformers.scala:30)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.transform(TypingTransformers.scala:40)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.scala$tools$nsc$transform$UnCurry$UnCurryTransformer$$super$transform(UnCurry.scala:451)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.mainTransform(UnCurry.scala:507)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.transform(UnCurry.scala:94)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.transform(UnCurry.scala:65)
        at scala.reflect.api.Trees$Transformer.transformTemplate(Trees.scala:2563)
        at scala.reflect.internal.Trees$$anonfun$itransform$4.apply(Trees.scala:1401)
        at scala.reflect.internal.Trees$$anonfun$itransform$4.apply(Trees.scala:1400)
        at scala.reflect.api.Trees$Transformer.atOwner(Trees.scala:2600)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.atOwner(TypingTransformers.scala:30)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.atOwner(TypingTransformers.scala:25)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.atOwner(TypingTransformers.scala:17)
        at scala.reflect.internal.Trees$class.itransform(Trees.scala:1399)
        at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16)
        at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16)
        at scala.reflect.api.Trees$Transformer.transform(Trees.scala:2555)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.transform(TypingTransformers.scala:44)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.mainTransform(UnCurry.scala:510)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.transform(UnCurry.scala:94)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.transform(UnCurry.scala:65)
        at scala.reflect.api.Trees$Transformer$$anonfun$transformStats$1.apply(Trees.scala:2589)
        at scala.reflect.api.Trees$Transformer$$anonfun$transformStats$1.apply(Trees.scala:2587)
        at scala.collection.immutable.List.loop$1(List.scala:172)
        at scala.collection.immutable.List.mapConserve(List.scala:188)
        at scala.reflect.api.Trees$Transformer.transformStats(Trees.scala:2587)
        at scala.reflect.internal.Trees$class.itransform(Trees.scala:1397)
        at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16)
        at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16)
        at scala.reflect.api.Trees$Transformer.transform(Trees.scala:2555)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.scala$tools$nsc$transform$TypingTransformers$TypingTransformer$$super$transform(TypingTransformers.scala:40)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer$$anonfun$transform$1.apply(TypingTransformers.scala:40)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer$$anonfun$transform$1.apply(TypingTransformers.scala:40)
        at scala.reflect.api.Trees$Transformer.atOwner(Trees.scala:2600)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.atOwner(TypingTransformers.scala:30)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.transform(TypingTransformers.scala:40)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.scala$tools$nsc$transform$UnCurry$UnCurryTransformer$$super$transform(UnCurry.scala:451)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.mainTransform(UnCurry.scala:507)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.transform(UnCurry.scala:94)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.transform(UnCurry.scala:65)
        at scala.reflect.api.Trees$Transformer.transformTemplate(Trees.scala:2563)
        at scala.reflect.internal.Trees$$anonfun$itransform$4.apply(Trees.scala:1401)
        at scala.reflect.internal.Trees$$anonfun$itransform$4.apply(Trees.scala:1400)
        at scala.reflect.api.Trees$Transformer.atOwner(Trees.scala:2600)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.atOwner(TypingTransformers.scala:30)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.atOwner(TypingTransformers.scala:25)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.atOwner(TypingTransformers.scala:17)
        at scala.reflect.internal.Trees$class.itransform(Trees.scala:1399)
        at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16)
        at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16)
        at scala.reflect.api.Trees$Transformer.transform(Trees.scala:2555)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.transform(TypingTransformers.scala:44)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.mainTransform(UnCurry.scala:510)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.transform(UnCurry.scala:94)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.transform(UnCurry.scala:65)
        at scala.reflect.api.Trees$Transformer$$anonfun$transformStats$1.apply(Trees.scala:2589)
        at scala.reflect.api.Trees$Transformer$$anonfun$transformStats$1.apply(Trees.scala:2587)
        at scala.collection.immutable.List.loop$1(List.scala:172)
        at scala.collection.immutable.List.mapConserve(List.scala:188)
        at scala.reflect.api.Trees$Transformer.transformStats(Trees.scala:2587)
        at scala.reflect.internal.Trees$$anonfun$itransform$7.apply(Trees.scala:1419)
        at scala.reflect.internal.Trees$$anonfun$itransform$7.apply(Trees.scala:1419)
        at scala.reflect.api.Trees$Transformer.atOwner(Trees.scala:2600)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.atOwner(TypingTransformers.scala:30)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.atOwner(TypingTransformers.scala:25)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.atOwner(TypingTransformers.scala:17)
        at scala.reflect.internal.Trees$class.itransform(Trees.scala:1418)
        at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16)
        at scala.reflect.internal.SymbolTable.itransform(SymbolTable.scala:16)
        at scala.reflect.api.Trees$Transformer.transform(Trees.scala:2555)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.scala$tools$nsc$transform$TypingTransformers$TypingTransformer$$super$transform(TypingTransformers.scala:40)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer$$anonfun$transform$2.apply(TypingTransformers.scala:42)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer$$anonfun$transform$2.apply(TypingTransformers.scala:42)
        at scala.reflect.api.Trees$Transformer.atOwner(Trees.scala:2600)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.atOwner(TypingTransformers.scala:30)
        at scala.tools.nsc.transform.TypingTransformers$TypingTransformer.transform(TypingTransformers.scala:42)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.mainTransform(UnCurry.scala:510)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.transform(UnCurry.scala:94)
        at scala.tools.nsc.transform.UnCurry$UnCurryTransformer.transform(UnCurry.scala:65)
        at scala.tools.nsc.ast.Trees$Transformer.transformUnit(Trees.scala:147)
        at scala.tools.nsc.transform.Transform$Phase.apply(Transform.scala:30)
        at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:430)
        at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:397)
        at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:397)
        at scala.collection.Iterator$class.foreach(Iterator.scala:743)
        at scala.collection.AbstractIterator.foreach(Iterator.scala:1174)
        at scala.tools.nsc.Global$GlobalPhase.run(Global.scala:397)
        at scala.tools.nsc.Global$Run.compileUnitsInternal(Global.scala:1625)
        at scala.tools.nsc.Global$Run.compileUnits(Global.scala:1610)
        at scala.tools.nsc.Global$Run.compileSources(Global.scala:1605)
        at scala.tools.nsc.Global$Run.compile(Global.scala:1703)
        at xsbt.CachedCompiler0.run(CompilerInterface.scala:123)
        at xsbt.CachedCompiler0.run(CompilerInterface.scala:99)
        at xsbt.CompilerInterface.run(CompilerInterface.scala:27)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:483)
        at sbt.compiler.AnalyzingCompiler.call(AnalyzingCompiler.scala:102)
        at sbt.compiler.AnalyzingCompiler.compile(AnalyzingCompiler.scala:48)
        at sbt.compiler.AnalyzingCompiler.compile(AnalyzingCompiler.scala:41)
        at sbt.compiler.AggressiveCompile$$anonfun$3$$anonfun$compileScala$1$1.apply$mcV$sp(AggressiveCompile.scala:98)
        at sbt.compiler.AggressiveCompile$$anonfun$3$$anonfun$compileScala$1$1.apply(AggressiveCompile.scala:98)
        at sbt.compiler.AggressiveCompile$$anonfun$3$$anonfun$compileScala$1$1.apply(AggressiveCompile.scala:98)
        at sbt.compiler.AggressiveCompile.sbt$compiler$AggressiveCompile$$timed(AggressiveCompile.scala:159)
        at sbt.compiler.AggressiveCompile$$anonfun$3.compileScala$1(AggressiveCompile.scala:97)
        at sbt.compiler.AggressiveCompile$$anonfun$3.apply(AggressiveCompile.scala:142)
        at sbt.compiler.AggressiveCompile$$anonfun$3.apply(AggressiveCompile.scala:86)
        at sbt.inc.IncrementalCompile$$anonfun$doCompile$1.apply(Compile.scala:38)
        at sbt.inc.IncrementalCompile$$anonfun$doCompile$1.apply(Compile.scala:36)
        at sbt.inc.Incremental$.cycle(Incremental.scala:73)
        at sbt.inc.Incremental$$anonfun$1.apply(Incremental.scala:33)
        at sbt.inc.Incremental$$anonfun$1.apply(Incremental.scala:32)
        at sbt.inc.Incremental$.manageClassfiles(Incremental.scala:41)
        at sbt.inc.Incremental$.compile(Incremental.scala:32)
        at sbt.inc.IncrementalCompile$.apply(Compile.scala:26)
        at sbt.compiler.AggressiveCompile.compile2(AggressiveCompile.scala:150)
        at sbt.compiler.AggressiveCompile.compile1(AggressiveCompile.scala:70)
        at sbt.compiler.AggressiveCompile.apply(AggressiveCompile.scala:45)
        at sbt.Compiler$.apply(Compiler.scala:70)
        at sbt.Defaults$.sbt$Defaults$$compileTaskImpl(Defaults.scala:736)
        at sbt.Defaults$$anonfun$compileTask$1.apply(Defaults.scala:730)
        at sbt.Defaults$$anonfun$compileTask$1.apply(Defaults.scala:730)
        at scala.Function1$$anonfun$compose$1.apply(Function1.scala:47)
        at sbt.$tilde$greater$$anonfun$$u2219$1.apply(TypeFunctions.scala:42)
        at sbt.std.Transform$$anon$4.work(System.scala:64)
        at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:237)
        at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:237)
        at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:18)
        at sbt.Execute.work(Execute.scala:244)
        at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:237)
        at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:237)
        at sbt.ConcurrentRestrictions$$anon$4$$anonfun$1.apply(ConcurrentRestrictions.scala:160)
        at sbt.CompletionService$$anon$2.call(CompletionService.scala:30)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:744)

--
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.
Scala Mailing Lists | 21 Mar 15:32 2014
Picon
Picon

Mailing list reminder: Scala-debate

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

This list is a more relaxed forum for Scala discussions
that would probably be off-topic or too convoluted for
the other lists, but that may still be quite interesting
to follow for a selected readership.

In particular, the following are appropriate:

  * threads that evolved beyond their initial topic,
      and have become too long or convoluted to be
      of interest to most readers
  * threads discussing extremely specialized topics
  * threads that are mostly speculative in nature,
      out-of-the-box thinking, philosophical views
      (as long as they are still somehow related
      to Scala)
  * debates (of course)

The "Scala-debate" list is the natural destination of all
the threads that start on other mailing lists, but are no
longer on topic on their original list, or have turned
into an in-depth debate about something.

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

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-debate/subscribe
or send an email to scala-debate+unsubscribe <at> googlegroups.com

Thank you!
The Scala Team

--

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