Matan Safriel | 30 Oct 21:21 2014
Picon

type definitions => first class citizens

Hi,

If I'm not mistaken, type definitions cannot be defined outside a class, object, or package object, in all Scala versions to date. 
While it's very easy to use a package object, this is really a case where the language does not shine and gets in your way when trying to write "good" code in a fluent, domain modelling focus. 

Example: you have a certain domain type heavily used across your application. In domain type, I mean a type that logically is part of the domain or problem you are modelling, not a type of the Scala or other programming language. Rather than using the "String" scala type for that domain type, you would rather give it a special type name of its own, so that later, when you evolve your model, you would turn it into a class, or just later enjoy compiler protection for it. Otherwise, you would later not know, nor will the compiler, that certain "String" values belong to that domain type and others are just "String" values that do not mimic the same domain type. By assigning a type name, you can later refactor to a slightly different type definition for your own defined type, and have the change "propagate" to all places where you used the type name. The code implies the domain logic.

Now to enjoy this, you have to use a package object, which is a rather annoying being, but that is not the issue. The issue is that a type definition from an OO perspective is not very different than a class. And classes can just be defined in your code, whereas a type definition must be constrained to definition inside a class, or a package object hack. I think all types, be they type definitions, classes or what else, should be same class citizens.

I think this does not make sense and certainly an area for improvement in forthcoming versions of the language - it is one example of how Scala can do so many cool things, but overlooks some simple things that small projects start from. I think this is more helpful than fancy things that only PhD's with a lifetime of Haskell programming will use. I can also hope this is only a relatively small change to make! 

Happy to hear what you think,
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.
Owen | 25 Oct 09:05 2014
Picon

Implicit shadowing rules surprise me every time

So, I make a handy little implicit:
implicit class As[T](n: T) { def as(f: => Unit) = { f n } }
So that I can use it like
var i: Int = 0 println(i as (i += 1))Except darn, I forgot I also had this list of chemical elements
object Elements { // ... val Ga = 31 val Ge = 32 val As = 33 // ... }and had imported them like so
import Elements._Now, I see the compiler tell me that

Error:(37, 31) value as is not a member of Int
            println(i as (i += 1))
                      ^


And what am I to do? I end up resorting to -Xlog-implicits.

But, seriously, what does that fact that both the throw-away wrapper class and the element happen to have the same name really have to do with anything? I don't even write the word `As` in my program; I'd really rather it not have a name at all; I'm certainly not referring to it by name; there's certainly no ambiguous use of the word `As`.  I will never understand...

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

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.

Gmane