Scala Mailing Lists | 21 Oct 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
(Continue reading)

Radek Slupik | 16 Oct 22:23 2014
Picon

Structural types without reflection

I think it is possible to implement structural types without reflection. Let

def f(x: { def a: Int; def b: String }) = {
  x
.a + x.b
  g
(x)
}

def g(x: Any) = ()

class A { def a = 1; def b = "x" }

f
(new A())

desugar to the following:

trait $compilerInventedName {
 
def $wrappedValue: Any

 
def a: Int
 
def b: String
}

def f(x: $compiler_invented_name) = {
  x
.a + x.b
  g
(x.$wrappedValue)
}


def g(x: Any) = ()

class A { def a = 1; def b = "x" }

val $compilerInventedVariable
= new A()
f
(new $compilerInventedName {
  override def $wrappedValue = $compilerInventedVariable
 
override def a = $compilerInventedVariable.a
 
override def b =
$compilerInventedVariable.b
})

And when converted to a different type, $wrappedValue is extracted first.

The only issue I see is eq and ne, although I think those can be special-cased to access $wrappedValue when used on objects of structural types.

--
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.
Eric Kolotyluk | 10 Oct 00:37 2014
Picon

Is Modern Web App Programming the Antithesis of Fun Programming?

I recently got a job with a company that is a Scala shop - oh joy - using Typesafe Akka and Play - oh joy oh joy.

I was so happy, and looking forward to using what I had learned in Coursera Functional Programming in Scala.

Alas, I have had to pitch in on the front-end work, using Javascript, jQuery, Knockout, Sammy, Bootstrap, Conquer, etc.

<vent>
OMG - everything is based on side effects and mutable data structures everywhere. On top of that, typeless Javascript is a bloody nightmare, and object-oriented programming using prototypes is insane. Boilerplate everywhere.

Programming this way is definitely not fun, as in, unpleasant, frustrating, insane, stressful, etc. Everything is spaghetti. It takes insanely long to do the most simple things, and code is practically impossible to reverse engineer. It is so hard to reason about things I feel like I am loosing my mind, and everything you do is: hack a little, hack a little more, pray, pray, pray, keep hacking. Is also seems highly dysfunctional, as in, as far away from FP as you can get.
</vent>

Now that I got that out of my system, I am wondering what the future holds for front-end programming. I hope that Scala.js will tame some of the insanity, but I somehow feel that the current paradigm of web app implementation is deeply flawed in too many fundamental ways. Certainly Scala.js will at least bring static type checking, but can we find ways to minimize or eliminate side effects and mutable data?

Part of me wonders if James Gosling was on the right track with NeWS, but that did not last long. And why did running Java byte code in the web browser fail so badly that we ended up with what seems to be the worst case of all software development environments possible?

Am I just suffering web app developer shock, or do other people have concerns about how this model of programming that has evolved?

Cheers, Eric

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

Joshua Cason | 9 Oct 20:50 2014
Picon

Why not make val the default?

Sorry this is a little gripey, but... Why not treat val as the default for defining objects? One thing I love about Scala is that, without semicolons and with type inference, coding is less verbose and more of a joy. But, dangit, how about we get rid of val and just use var when we want to make something mutable? It's already default in function parameters. In Java do we have static and non-static keywords? Final and non-final? No, things are just non-static and non-final by default.

Welcome to Scala version 2.AWESOME (OpenJDK 64-Bit Server VM, Java 1.7.0_55).
Type in expressions to have them evaluated.
Type :help for more information.

scala> thisPostIsRight = true
thisPostIsRight: Boolean = true

Both pleased and displeased,
Josh

--
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.
Matan Safriel | 5 Oct 11:32 2014
Picon

Shapeless and scala core

Do you foresee features from Shapeless such as polymorphic function values and heterogenous lists, making it into the scala core, or working in a very performant and robust way on top the scala core? (not to mention surviving breaking changes in scala language future releases).

--
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.
Matan Safriel | 25 Sep 19:31 2014
Picon

Implicit compilation errors when mixing slick and akka imports

Hi, 

This a small frustration about Scala as it is about Slick.
Introducing the following direct SQL access imports into otherwise working slick code:

import scala.slick.driver.JdbcDriver.backend.Database
import Database.dynamicSession

A previously working session implicit stops working with scala.slick.SlickException: No implicit session available;

As much as I recall from a similar case with Akka imports, there is no proper/documented way to realize there is a collision behind the scenes regarding an implicit. I assume it may be the same case here, although I intuitively realized these imports introduced the regression and just removed them to solve. Previously with Akka, scala complained about no implicit being available whereas in fact there were two of them available.

Hopefully this friction can be avoided in the future, or at least mentioned as an eye catching warning at the top of http://slick.typesafe.com/doc/2.0.0/sql.html.

I think there's something fundamentally broken in Scala or TypeSafe Scala libraries with how implicits are handled in compilation errors. I read the Scala community code of conduct, this is not intended as a snide comment but as a suggestion for making things more coder friendly when it comes to avoiding implicit black holes in compilation scenarios.

-matan

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

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.

Gmane