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.
Kevin Mas Ruiz | 26 Jul 22:11 2014
Picon

Doubts about Scala language design

Hi,

I love programming language design and I've started to learn Scala about two months ago. Coming from a very functional style programming (but having basic knowledge about OOP) I started having doubts about different Scala approaches to some problems. I wanted to discuss them here because I think it's a very interesting debate and maybe we could learn a lot about it.

The first thing are traits. I don't understand why Scala supported traits. If they wanted sharing a default implementation of a method between different types by inheritance, why not using multiple class inheritance as C++?  Me, as a rookie in Scala, I doubt when using traits and abstract classes sometimes. I normally use abstract class when inheritance is very complex and is more about data than behavior and traits for applying implicits on scopes I want (for example, implicits for casting a type A to B directly for easy integration with a third-party library). Is that a good methodology or should I think about other things?

The second thing is about function and method combination. I come from Common Lisp and one of the features I love is the ability to inject code before and after any method known at compile time or runtime. It's very useful for security access injection on a service oriented architecture or simply logging. For example in CL we could do something as this:

(if logging-enabled-p (defmethod save :before ((repository repository) any-object) (log "inserting ~a via ~a~%" any-object (name repository))))


In Scala, would be lovely to do so, for example, as this:

trait Logging {
   
def name: String
   
def before save(o: Any) { log("inserting %s via %s", o.toString, name) }
}


And then doing something like this:

if (loggingEnabled) {
   fooRepository
= new FooRepository with Logging
}


This is useful because we can define a lot of logic that is easy to maintain using a declarative approach (as logging and security) and should be layered out of the main implementation of our system. For example:

abstract class FooService {
   
def someAdminAction(withData: Foo): Foo
}


class FooServiceImpl extends FooService {
 
def someAdminAction(withData: Foo): Foo = veryComplexLogic(withData)
}


trait
SecuredFooServiceAspect(val user: User) extends FooService {
 
def before someAdminAction(withData: foo): Foo = {
     
if (user.canDoThis) {
         someAdminAction
(withData) // delegates to the next implemetation
   
} else {
       
throw new InvalidAccessException(user)
   
}
 
}
}


Why something like this has not been implemented in Scala? Would be a good idea acquiring this tool in the language? Maybe it can be done using annotations resolved at compile-time.

Another thing I don't now why Scala does not support is constant parameter dispatching as does Erlang. For example, in Erlang we can do something like this:

fac(0) -> 1;
fac
(N) when N > 0 -> N*fac(N-1).

This is a very useful and expressive approach for function definition and sometimes can be optimized at compile time (p.e a fac of a constant). I know that Scala has pattern matching (very useful) but I must admit that sometimes I avoid it because it's very verbose and complex for a lot of common cases. I would love Scala if I could do something as:

def save(foo: Foo) = DB.save(foo)
def save(None) {}

Which is far better than:

def save(foo: Foo) = {
   
if (foo != None) {
      DB
.save(foo)
   
}
   foo
}


This approach of "do-nothing-if-null" is very useful and taken a lot in other languages. For example, in C, free(NULL) does nothing (also delete null in C++)

Well, that's all. I didn't learn all of Scala so I'm sure in a future I will have more questions. Any idea about something I did? Any objections?

And after all, sorry for my English, I'm not very fluent writing it and I did my best. Also I accept corrections on this :)

Thank you all and hack Scala! 

--
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 | 22 Jul 07:12 2014
Picon

Maybe braces really are parens


I find it mildly peeve-inducing when people say that braces and parens are somehow interchangeable, but here is more evidence in their favor:

def f() {}  // an empty procedure

gets rewritten to

def f() = ()

Also, it's certainly a measure of some degree of desuetude in the community that this is what passes for Scala debate these days.

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