Owen | 17 Jan 23:12 2015
Picon

Why does zipping Options not produce an Option?

But the full signature shows that this is not exactly explicit; it's supposed to come out to an Option due to the CanBuildFrom magic. But I don't really understand CanBuildFrom that well...

--
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 | 16 Jan 18:50 2015
Picon

Fwd: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo

They said, "Fix ALL the Xlint warnings!"

We would say, "Fix _ the Xlint warnings!"

---------- Forwarded message ----------
From: joe darcy <joe.darcy <at> oracle.com>
Date: Thu, Jan 15, 2015 at 7:36 PM
Subject: And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo
To: jdk9-dev <at> openjdk.java.net


Hello,

After a small language change to make the effort tractable [1], and another round of code cleanup [2], the deprecation warnings have been eliminated from the build of the jdk repository of JDK 9 [3].

That means that coming after the previous waves of warnings cleanup, *all* the lint warnings are now enabled in the build of the jdk repo!

The effort of clearing all these lint warnings has taken place over many months building on the contribution of many people. I'd like to especially recognize Stuart Marks and Alan Bateman for early work cleaning up the libraries, Jan Lahoda for implementing the supporting language change, Jason Uh for help running build jobs, and Phil Race for many reviews of changes to client code.

Thanks,

-Joe

[1] JEP 211: Elide Deprecation Warnings on Import Statements, http://openjdk.java.net/jeps/211

[2] JDK-8066616 Suppress deprecation warnings in jdk libraries, https://bugs.openjdk.java.net/browse/JDK-8066616

[3] http://hg.openjdk.java.net/jdk9/dev/rev/f1dc16345985


--
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.
Ken Scambler | 13 Jan 00:58 2015
Picon

On the anti-modular traps of trait usage

As a counterpoint to Julian's thread about whether classes are necessary, I'd like to take this opportunity to complain/rant bitterly about popular anti-modular patterns of trait usage.

Traits shine as pure interfaces, typeclasses and as a kind of an abstraction over modules in the ML sense.

However, too frequently they are used as mixins in a way that exposes implementation details and couples all kinds of things together in a big mess.  It's often hard to untangle codebases written this way, and libraries that are written this way are all but unusable.

A common example is where the trait is a pseudo-OO-class, with methods that share data or state expressed through other fields:

trait BananaMasher {
  def banana: Banana
  def masher: Masher

  def mashBanana: Mush = masher.mash(banana)
}

trait BananaPeeler {
  def banana: Banana
  def peeler: Peeler
 
  def peelBanana: Peel = peeler.peel(banana)
}

trait Logging {
  def logger: LoggerImpl

  def info(str: String): Unit = logger.info(str)
  def error(str: String): Unit = logger.error(str)
}

class BananaManager extends BananaMasher with BananaPeeler with Logger {...}

The lovely "with" syntax looks and quacks like composition; it looks lovely!  We just throw everything together and it works...ish.

The trouble is that true composition should entail things not getting more complicated as you combine them.  In this case, BananaManager's API contains _everything_ provided by all the mixins, and all the wires are exposed, and its namespace is filled with gunk.  To understand BananaManager, you need to know _everything_ about all its mixins.  That isn't composition, that's ....accretion, or something!

There is a secret handshake between BananaPeeler and BananaMasher; there is a Banana field called "banana".  Is it deliberate? Do they rely on this as a way of talking to each other? Is it just an accident and this will result in a subtle bug?  Who knows!

You can see Logging thrown in -- this is a hard-wired side-effect, with a logging implementation baked in.  How will it be used by subclasses? What uses the effect? Who knows!

There is an illusion of flexibility given by the fact that all the details are overrideable as fields in the final cakey-muddle.  This is like that old cherished Spring ideal of "expose every wire in everything" that provides maximum configurability at the expense of any ability to figure out what anything is doing in isolation of everything else.

There is an illusion of modularity given by the sexy creation syntax: new This with That with TheOther; however it accumulates and exposes detail, that might interact in unpredictable ways.  Tests need to make all kind of unnecessary decisions on how to navigate the uncertainty and "togetherness".

It breaks my heart to see such a powerful language fall victim to the siren song of a sexy feature that can result in code that is often _worse_ (less modular, composable) than in more feature-poor languages! 

Scala gives us all the tools we need to write clean, modular, well-factored code.  Please consider trait usage carefully.

Cheers,
Ken

--
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.
Nick Stanchenko | 9 Jan 01:05 2015
Picon

Re: Re: Do you use classes?


I'm in the habit now of having no 'interesting' logic in my case classes. I would probably do what you did with `def name`, but for anything more interesting, it would get added on by an implicit conversion. I'm finding more and more that these 'interesting' things tend to be orthogonal concepts to the data (and applicable to many data types), so shouldn't really be baked into the data,
This is a good point. I strive to only add what’s essential for the data type in question, hence “properties” and not just any methods. A prime example of an orthogonal concept is serialization, which is particularly out of place if done with some magic annotations. It’s often not long before you find that you need to implement two “slightly” different JSON protocols...

although it is very nice to write it as myData.interestingOp rather than interestingOp(myData).
This might be the case of us being enslaved by the syntax rather than semantics. There is at least one language (unfortunately I can’t remember the name), where op(x, y, z) is the same as x.op(y, z) (no, I’m not talking about Python’s self).

Nick

M

On 8 January 2015 at 23:16, Nick Stanchenko <nick.stanch <at> gmail.com> wrote:
The more I use Scala, the more I tend to employ classes as either
  • parametrized modules (i.e. class is to an object what a def is to a val), or
  • algebraic data types,

but rarely for dynamic dispatch with inheritance and overriding — mixins with complementary final implementations seem more reasonable.

Like some people here, I found Haoyi’s perspective interesting:

Classes and mixins actually have completely different use cases, and it's kind of accident of history that they've been stuck together via inheritance, more because of ease-of-implementation than anything else.
Parametrized modules and ADTs also look like separate things stuck together, although I like properties in my case classes, as in

   

case class Person(firstName: String, lastName: String) {
 
def name = s"$firstName $lastName"
}

I wonder what their separation would look like.

Nick

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



--
Dr Matthew Pocock
Turing ate my hamster LTD

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

skype: matthew.pocock
tel: (0191) 2566550
mob: +447535664143

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

Julian Michael | 8 Jan 08:31 2015
Picon

Do you use classes?

Hello scala-debaters,

When I was writing some particularly OO/mix-inny code recently, I found that as I refactored, classes kept disappearing in favor of traits and objects until none of them were left.

Some reflection left me asking myself: why should we have classes at all?

First, I remembered Martin's comments I read here, especially this passage:

What we did in Scala was try to be more complete and orthogonal. We decided to have the same construction principles for all three sorts of members. So you can have abstract fields as well as value parameters. You can pass methods (or "functions") as parameters, or you can abstract over them. You can specify types as parameters, or you can abstract over them. And what we get conceptually is that we can model one in terms of the other. At least in principle, we can express every sort of parameterization as a form of object-oriented abstraction. So in a sense you could say Scala is a more orthogonal and complete language.

 Ok, cool. Orthogonal and complete. But then I remembered this discussion, in particular this passage from Martin (emphasis mine):

Ideally, Scala's types will be built from just traits, mixin composition, refinements, and paths, and nothing else. That's the true core of Scala as is captured in our dependent object types formalism. We'll throw in classes for Java compatibility. We still have to make this into a practical programming language compatible with what Scala currently is. The potential breakthrough idea here is to unify type parameters and abstract type members.
 
When I decided to compose this email I had only remembered the second bolded part—not the first. So it seems that my original question has a single answer, namely, Java compatibility. Removing classes from Scala, as far as I see it, would mean extending the idea of the second bolded part, and uniting constructor parameters with abstract fields (where the refactoring I mentioned earlier included changing the former to the latter).

This leaves me with one more question for you: Does today's good Scala code use classes? Do you? When? Do you think there are other good reasons for having them?

Best,
Julian

--
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 | 30 Dec 03:08 2014
Picon

Astonishing Lack of Comments and Documentation

As I work between the Java and Scala communities I am constantly astonished by the lack of comments and documentation in Scala code.

When I was in high school and university, on math tests if I did not show how I arrived at the answer, I did not get full marks, no matter how correct my answer was. Similarly, on computing science assignments I did not get full marks if there were no comments or documentation in the code.

When it comes to Scala I am constantly reminded of Martin Oderski's emphasis on being able to reason about code, yet the overwhelming trend I see in the Scala community is unreasonable code, code that is difficult or impossible to reason about.

In a sense, human readable comments are the lowest level of unit tests possible in code. For example

  def cliques =
    if (traversablePaths.isEmpty) Map.empty
    else traversablePaths.groupBy((path: Path) => path.toFile().length())

For some it may be pretty easy to figure out what this code is doing, and that it is probably correct. But: why are we doing this, and is this the right thing we want to do, and the right way to do this? How can we test our reasoning about the code if we know nothing about the context the code is being used in. Yet, this is exactly the pattern I see in over 90% of all Scala code I read.

  /**
     * A collection of files that all have identical length.
     */
  type Clique = Traversable[Path]

  /**
     * The collection of Cliques.
     *
     * Only files of the same length can ever be identical,
     * and getting file lengths from the file system is a cheap
     * and easy operation.
     */
  def cliques =
    if (traversablePaths.isEmpty) Map.empty
    else traversablePaths.groupBy((path: Path) => path.toFile().length())

  /**
     * Spread the cliques into groups of duplicate files.
     */
  def spreadDuplicates(clique: Clique) : List[DuplicateFiles] = {

By adding comments to the code we can now see the actual intent of the programmer, and we can now evaluate the implementation in the context of that intent. We can not only check (mentally unit test) the reasoning of the code in the programmer's own words, but the reasoning of the code in terms of how well that is expressed in Scala.

Furthermore, by using scaladoc (or javadoc) comments, there are more opportunities for people to check the reasoning in the code, APIs, etc. through a web site, or even better sill in the Scala IDE version 4 when you hover your mouse over declarations. Thank you so much version 4 :-)

Also, by structuring your types appropriately you create more opportunities for comments and documentation that make it easier to reason about what is really going on. For example, the Clique type used in the definition of spreadDuplicates, and immediately you can see that cliques is the plural of Clique, and what that means.

My personal belief is that if you are writing automated unit tests for your code, but you are not putting in adequate comments, then you have no idea what unit testing is about.

So how did we get to such a sad state in the Scala community?

While I personally have read many scala books, and taken the Coursera course Functional Programming in Scala, none of these training materials covers how to write comments or develop professional code documentation. Basically the problem is the leaders in the Scala community have made it abundantly clear that they do not care about comments and documentation, and consequently too many others now shares that same opinion.

The greatest defect in the Coursera course is the lack of education on comments and documentation. There should be an entire class on the this subject at the beginning, and every subsequent class should reinforce the practices.

At my most recent place of employment I was very dismayed to find almost no comments in any of our code. When I asked two of our developers why, they said that my predecessor told them not to put any comments in the code because over time the comments would become out of date when people changed the code and not the comments. I wish I had a dollar for every time I have heard that excuse. To some degree I feel that it is also because almost all of our code is Scala, people have adopted this attitude because of all their Scala training.

But what is it in particular in the Scala community that makes people so adverse to comments? My personal option is that too many people treat Scala like some sort of mathematical toy, or the reincarnation of APL, the embodiment of write-once code. "Oh look how few lines of code I can implement this idea, and if I use special characters I can drop the character count in my code even lower. Adding comments would increase my character count and make the code impure."

Typesafe are also to blame, in that while they have created this wonderful environment called Activator with many useful templates as examples to study and learn from, they have deliberately separated the need for code comments into tutorial comments. If you do not know there are tutorials and look at the code, all you see is one WTF.scala file after another. Basically Typesafe are promoting this notion that code comments and documentation are not worthy of their time, and consequently not worthy of anyone else's time.

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

Russ Paielli | 14 Dec 04:30 2014
Picon

Fwd: indentation consistency checks

I see your point, but I think this kind of check goes beyond a "lint" check. When you see something like

if (condition)
    exp1
    exp2

I contend that that is almost certainly a bug and shouldn't just be left for a style checker or lint tool to find. Most "lint" checks are for things that are significantly less likely to be bugs.

Note also that not everyone uses a style checker or lint tool. When getting started with Scala, it takes enough time just to decide which build tool and IDE to use. Let's not force people to choose a style checker too just to get basic checks.

On Sat, Dec 13, 2014 at 4:56 PM, Simon Schäfer <mail <at> antoras.de> wrote:

On 12/14/2014 01:27 AM, Russ Paielli wrote:
Well, if it's so darn easy it should be in the compiler. That was my whole point. Why should I have to bother with another application such Scalastyle just to get this check?
Because it is extensible. Maintaining a lot of linting rules in a single repository is difficult and there are too many different use cases to make everyone happy. Independent linters make extensions easy. A further integration into IDEs and other tools also gets more straightforward because it can be done by everyone and not just the few maintainers of the compiler (not to mention that there exist multiple compilers, shall all of them reimplement the same linting rules?).
This is not just about style. It's about correctness. If you are worried about compiler speed, simply require a flag for activation. That's my opinion anyway.

On Sat, Dec 13, 2014 at 4:15 PM, Simon Schäfer <mail <at> antoras.de> wrote:

On 12/14/2014 12:27 AM, Russ P. wrote:
I would like to see compiler checks for basic indentation consistency. Let me explain.

Consider code blocks with one line:

if (condition)
    expression
...

or

def method(args ...) =
    expression

As a minimalist I don't like to see curly braces for one-liners where they are unnecessary, so I leave them out. However, if I then decide to add a line and forget to add braces,

if (condition)
    expression1
    expression2

I have a bug that could possibly be difficult and time-consuming to track down (or could cause a jetliner to hit a nuclear power plant just as they are removing spent fuel rods and a class of kindegardners is touring the facility!). This is a very easy mistake to make (particularly if you have written a lot of Python code!). But the inconsistency here between the indentation structure and the logical structure should be very easy for the compiler to detect. I think the compiler should provide a warning in these cases. Or at least there should be a flag to activate such warnings in case someone does not want them for some reason (although I can't imagine why anyone would want such inconsistencies in their code).
This is a problem that can easily detected by a syntax checker like Scalastyle - there is no need to ask a slow compiler for such a check (and extending Scalastyle is easy and can be done completely by yourself).

Furthermore, if you write expression based code, such an error gets impossible. It only can happen when you have consecutive side effecting statements, which are often necessary in Scala (due to the lack of an IO monad). Nevertheless, it is possible to minimize such side effects or hide them behind other expressions.

--Russ



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

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


--

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


--


--

--
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 Schäfer | 14 Dec 01:56 2014
Picon

Re: indentation consistency checks


On 12/14/2014 01:27 AM, Russ Paielli wrote:
Well, if it's so darn easy it should be in the compiler. That was my whole point. Why should I have to bother with another application such Scalastyle just to get this check?
Because it is extensible. Maintaining a lot of linting rules in a single repository is difficult and there are too many different use cases to make everyone happy. Independent linters make extensions easy. A further integration into IDEs and other tools also gets more straightforward because it can be done by everyone and not just the few maintainers of the compiler (not to mention that there exist multiple compilers, shall all of them reimplement the same linting rules?).
This is not just about style. It's about correctness. If you are worried about compiler speed, simply require a flag for activation. That's my opinion anyway.

On Sat, Dec 13, 2014 at 4:15 PM, Simon Schäfer <mail <at> antoras.de> wrote:

On 12/14/2014 12:27 AM, Russ P. wrote:
I would like to see compiler checks for basic indentation consistency. Let me explain.

Consider code blocks with one line:

if (condition)
    expression
...

or

def method(args ...) =
    expression

As a minimalist I don't like to see curly braces for one-liners where they are unnecessary, so I leave them out. However, if I then decide to add a line and forget to add braces,

if (condition)
    expression1
    expression2

I have a bug that could possibly be difficult and time-consuming to track down (or could cause a jetliner to hit a nuclear power plant just as they are removing spent fuel rods and a class of kindegardners is touring the facility!). This is a very easy mistake to make (particularly if you have written a lot of Python code!). But the inconsistency here between the indentation structure and the logical structure should be very easy for the compiler to detect. I think the compiler should provide a warning in these cases. Or at least there should be a flag to activate such warnings in case someone does not want them for some reason (although I can't imagine why anyone would want such inconsistencies in their code).
This is a problem that can easily detected by a syntax checker like Scalastyle - there is no need to ask a slow compiler for such a check (and extending Scalastyle is easy and can be done completely by yourself).

Furthermore, if you write expression based code, such an error gets impossible. It only can happen when you have consecutive side effecting statements, which are often necessary in Scala (due to the lack of an IO monad). Nevertheless, it is possible to minimize such side effects or hide them behind other expressions.

--Russ



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

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


--

--
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. | 14 Dec 00:27 2014
Picon

indentation consistency checks

I would like to see compiler checks for basic indentation consistency. Let me explain.

Consider code blocks with one line:

if (condition)
    expression
...

or

def method(args ...) =
    expression

As a minimalist I don't like to see curly braces for one-liners where they are unnecessary, so I leave them out. However, if I then decide to add a line and forget to add braces,

if (condition)
    expression1
    expression2

I have a bug that could possibly be difficult and time-consuming to track down (or could cause a jetliner to hit a nuclear power plant just as they are removing spent fuel rods and a class of kindegardners is touring the facility!). This is a very easy mistake to make (particularly if you have written a lot of Python code!). But the inconsistency here between the indentation structure and the logical structure should be very easy for the compiler to detect. I think the compiler should provide a warning in these cases. Or at least there should be a flag to activate such warnings in case someone does not want them for some reason (although I can't imagine why anyone would want such inconsistencies in their code).

--Russ



--
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 | 9 Dec 06:47 2014

objects overriding vals have a strange "dual citizenship"

The following code gives a rather peculiar error:

object PathTest { trait A { class S } trait B { val a: A def f(s: a.S) } object b extends B { object a extends A def f(s: a.S) = ??? } }
Error:(13, 10) object creation impossible, since method f in trait B of type (s: PathTest.b.a.S)Unit is not defined (Note that B.this.a.S does not match PathTest.b.a.S: their prefixes (i.e. enclosing instances) differ) object b extends B { ^
If instead b.a is defined as

val a = new A { }

Then the error goes away. It seems that object a lives in a gray zone where it has its own singleton type as all objects do, but because it does not explicitly override B#a with its singleton type, the definition of f is unaffected.

The error message is also a bit odd since B.this.a.S and PathTest.b.a.S are in fact the same instance.

--
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 | 8 Dec 21:46 2014
Picon

Why does Scala create new path dependent types in val definitions?

I'm referring to the type mismatch in

trait W { type A } val w1 : W = ??? val w2 = w1 (??? : w2.A) : w1.A
Proving equality in general is difficult and subtle, but in the fairly common case of val a = b where b is also a stable value, a rewrite to val a: b.type = b seems harmless and concise.

At first I thought maybe the current behavior was to allow the user to easily create new path dependent types without fearing that the compiler would derive them to be equal; but I do not think that this justification holds since there would be essentially the argument in

trait W { type A } object w1 extends W val w2 = w1 (??? : w2.A) : w1.A
where there is no type error.

If a rewrite to val a: b.type = b is harmful for some reason (which seems somewhat plausible, because it alters the LHS based on a special case of the RHS), perhaps a keyword like alias a = b could be used instead. alias could additionally be given the behavior that a is not in scope for the RHS, eliminating a common annoyance when creating anonymous subclasses of traits.

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