Haoyi Li | 13 Nov 20:34 2014
Picon

Making obj.method.foo eta-expand obj.method without the (... _) wrapper?

It would be very nice to do things like obj.method.tupled rather than (obj.method _).tupled. Basically nobody does this right now because it's hideous, but that's not inherent to the concept of .tupled, that's more because we deal with methods more often than we deal with functions, and most-often-times this is handled transparently (e.g. by target typing) but in cases where you want to call methods on the function, it doesn't work.

More broadly, I think doing automated eta-expansion for method-calls-on-methods would allow for new styles of code which currently don't exist purely due to ugliness. People don't currently put any extension methods of FunctionNs because of this ugliness, but you could imagine from

obj.method: (T, V) => R

You can have APIs such as

obj.method.curried: T => V => R
obj.method.liftA: (A[T], A[V]) => A[R]
obj.method.macroRemoteProxy: (T, V) => Future[R]

etc. 

To do this, my idea would be that any case where you have something of the form

a.b.c

and b is a method with >1 non-implicit argument list, it would be translated to 

(a.b _).c

I'm going to to ignore the 0-or-1 argument list case, because that suffers from the "0 arg lists functions are callable with 0 or 1 arg lists" property, which I think is a huge mistake, but won't be fixable while preserving backwards compatibility.

I'm putting this out here to get some feedback. Is this theoretically impossible? Practical? As far as I can tell it'd preserve backwards compatibility, but I don't know if I'm missed something. Is it something that people would even find desirable?

--
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.
Dave Lloyd | 12 Nov 15:13 2014
Picon

Implicit imports from objects

Hi,

First time poster here and recent convert to Scala. I've been using Java for the last ****  years but before that, my favourite language was Algol68 and Scala satisfies a lot of my desire for a concise, seductive and powerful notation.

I've lots of questions and thoughts about Scala, but I'll start with this one (probably a FAQ but couldn't find anything): 
Why doesn't Scala import the declarations from an object into its companion class? 
It seems unnecessary to write import Object._ or explicitly reference the common namespace. In Java, statics are in the same scope as instance methods.

--
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 | 12 Nov 10:05 2014
Picon

about making simple things simpler for next versions of Scala

Hi,

This is just a quick follow-up to https://groups.google.com/forum/#!topic/scala-user/5fH9BHjPzOQ.
Why not add "in" to the collections library? it is such a common idiom in other languages... the syntax is typically if a in b.

I think the language should carefully (and selectively) focus on making simple things simple for the coder, not only on complicated haskell-like constructs like things inspired from Shapeless et al (which are also great!).
Just wondering if this and/or similar things are considered for the next versions... e.g. I would also add type definitions being equal citizens (classes) and not just local aliases, which would allow modelling domains around classes in more natural ways, and consider the "unless" keyword. Although falling into somewhat different categories under the hood, these are all things that make doing simple things simple by the coder user. I think it is important to make it so that simple things are simple and idiomatic, aside the focus on extra-complicated functional constructs.. 

Last to add to the list, if I may, last I checked it was still necessary to access a key pair in a map as ._1 and ._2. While this makes sense mathematically, I think the core library should make them accessible as .key and .value as well, to make code more readable. This too in the same vein, I hope the connecting vein of thought is clear to see, it is, that it's not enough that something simple/intuitive should be possible to code somehow, but it should be simple to code; I think there is a widening gap at this. While compiler errors in many cases show good design-for-the-coder, sometimes (but not always) even remarkably so, I think the language core is not at par. I think it needs to push more into making simple things simple to the coder.. it seems to me it's not enough that something simple can be accomplished in some complicated way - it should be simple to the coder otherwise the language is creating a lot of uncalled for coding friction. 

Since Scala is an evolving language, I understand backwards compatibility is weighted in and not everything can be changed, but I do think these changes or a similar set should have their own task-force for the next versions of scala, so that it can get wider adoption over time. I write it because I care and I think there is a lot of potential in pursuing such a humble goal.

I hope it will be realized that simplicity can have a huge impact on onboarding team members to Scala as well.

Thanks,
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.
thinking | 6 Nov 16:04 2014
Picon

Scala learning prerequisites

Hi,

   I am programming in python. I know python. But I do not have any programming knowledge in Java/C++. I do have C language knowledge.
   I have few questions about scala language :-

   Is java/c++ knowledge required to learn scala ?  
   Is scala easy to learn language like python ?
   What are the challenges for me to learn scala?
 
   What is the future of scala language ?
   

Thanks, 
     

--
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.
Ruslan Shevchenko | 6 Nov 12:23 2014
Picon

Odessa.UA Java/Scala lab [6. Dec. 2014] : call for speakers.

Good day, colleagues.

I want to draw you attention to Java/Scala Lab conference which will be held in Odessa (Ukraine)  6. Dec. 2014

The conference will gather more than 200 software developers from Ukraine.   Topics will include practical usage of java/scala technologies, application of java/hadoop  and scala/spark stack for big data processing, future development and adaptation of those technologies.  

  So, if you have something interesting to tell [working languages are English/Russian/Ukrainian] and you schedule allows you to visit Odessa at this time - please, fill next form:  https://docs.google.com/forms/d/1xir6Dla7_PosTyUkuzBq-W6tAbqWJqwGPXV8BwFErR4/viewform

Regards !



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

Gmane