reynaldo.gil | 18 Sep 07:40 2014

Automatic val declaration

Can the language be modified so that all new variables in the left side of an assignment be considered a val declaration. For example:
"a=3" be the same than "val a=3". I'm boring  due to type so many "val". I think is is bureaucratic and the compiler can infer that. Also in this way the language enforce the use of val over var. What do you think in wrong in that? Thanks Gil

--
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.
Owen | 5 Sep 23:41 2014

Should there be protections against inferring non-covariant types?

Everyone knows that inferring non-covariant types can be unreliable. It seems that this can trip up new-comers who don't realize that an explicit type might be needed to solve their problem:

Stack Overflow: Scala Map with Either


Other common examples are:

var x = 0
x += 0.5


List(1, 2, 3).foldLeft(None) { (a, b) => Some(b) }

Perhaps the compiler could warn or error in these situations?

--
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 | 2 Sep 18:23 2014
Picon

Typelevel Scala and the future of the Scala ecosystem

--
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.
Naftoli Gugenheim | 29 Aug 13:53 2014
Picon

Infer type parameters

Not long ago I wanted to translate and F# library (Piglets [http://www.cs.ru.nl/P.Achten/IFL2013/symposium_proceedings_IFL2013/ifl2013_submission_29.pdf]) to Scala, so I got some exposure to F# syntax.


In F# you can leave off method type parameters and parameter types pretty often. Partially this is because of forward type inference. But would it be useful if in scala you could write

def m(a, b) = ???

and have it translated to

def m[A, B](a: A, b: B) = ???

for you?


--
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.
Andy Hicks | 26 Aug 11:42 2014
Picon

Scala eXchange 2014 CfP, Reminder- Closes this Sunday (31-Aug)

Scala eXchange 2014
================
London,UK 
8th - 9th December at Business Design Centre, London

Submit talks:  http://bit.ly/scalax14


Call for Presentations 
--------------------------------

As a reminder to anyone who has been thinking of submitting a talk and 'just hasn't got around to it' the Call for Presentations closes on 31st August, that's this Sunday.

Working on a project using Scala and want to share your experiences? Have something interesting to say on Scala best practises? Or work a really great open source project? Then we want to hear from you!

Full details on what we're looking for, submission timings, and how to apply - head to http://bit.ly/scalax14

Full details of ScalaExchange2014 can be found at


Any questions can be sent to:  scalax <at> skillsmatter.com

Hope to see you in December



--
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.
Ryan Schmitt | 21 Aug 23:23 2014
Picon

Postfix Ops MUST be enabled by Default

It has been a while since I bothered to update my DSL library to the latest version of Scala, yet to my surprise it was riddled with warnings from SIP 18. In the documents, I recommend using postfix operations to make the code read naturally, but once SIP 18 goes into full effect, users will be forced to add command line parameters or add some unneeded imports just to use some sample code.

It should be needless to say that this is a terrible solution. The normal objections to SIP 18 aside, this is just silly. I trust my users enough to understand the effect of adding a newline with postfix operations, but they should not be forced to add clutter to their code every time they want to perform a basic interaction. If normal usage requires an import, it is hardly a DSL anymore.

--
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.
Owen | 21 Aug 21:28 2014
Picon

Nested recursive import

Hello,

How about writing

import actors.{Actor._, _}

in place of

import actors._
import Actor._


Best,
Owen

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

Som Snytt | 7 Aug 09:40 2014
Picon

Scala impeccable slim-fit dotty shirts


My hopes were momentarily elevated at the thought of Scala slim-fit shirts!

http://www.sfgate.com/style/article/Cary-LaScala-s-cotton-shirts-slim-fit-perfect-5661480.php

Only to be dashed by the dots:

The subtle sophistication of dots.

They worked so hard to eliminate the dots.

My last bastion of optimism is that they might mean:

"The subtle sophistication of dotty."

I would definitely buy a Dotty t-shirt if it looks like this.

--
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.
Russ P. | 1 Aug 21:41 2014
Picon

suggestion: auto-generated copy constructor

It seems to me that the compiler should automatically generate a copy constructor for case classes. A copy constructor is easy to generate manually, but generating it automatically would reduce boilerplate and the potential for subtle errors. This would be similar to the automatic generation of the copy method for case classes.

For an example use case, I have a class called Route that represents the assigned route to be flown by an airplane. I need various plotting methods for development and testing, but I don't want to clutter the Route class with them, so I use an extension trait and an implicit conversion:

trait RoutePlotting extends Route { /* plotting utilities */ }

    implicit def addRoutePlotting(route: Route): Route with RoutePlotting =
        new Route(route) with RoutePlotting

I am calling my own copy constructor here, which relieved me of the error-prone task of passing all the constructor arguments through. However, I still need to maintain the Route copy constructor if I change the constructor signature. For example, if I add a new constructor argument with a default value, and I forget to pass the new argument to the copy constructor, it will compile with a hidden bug. At least my copy constructor is near the primary constructor so I am less likely to forget to keep them consistent, but with an auto-generated copy constructor there would be no possibility of inconsistency and boilerplate would be reduced. Thanks.

--Russ P.

--
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.
Andy Hicks | 27 Jul 17:30 2014
Picon

Scala-Swing - Community Support

As you may know scala-swing has been given the status of 'community supported'. 

If anyone is interested and would like to contribute to making swing usable with scala then I would welcome your help.

As this does easily fit within the scala-internals googlegroup (or that matter any of the others ) we've created a new scala-swing group  https://groups.google.com/forum/#!forum/scala-swing

Some of the initial changes have been changes 
- java7 - most/all of the new work will be put into the 'java7' branch for mainly practical reasons, however this branch is still compiled for java 6 and will work on on it and above.
- beginning to fix the Publisher 
- making the examples work in sbt

Any questions? please post to the google group.




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