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.
Meredith Gregory | 5 Dec 19:30 2014
Picon

Slides on delimited continuations

Dear Scalarazzi and Scalawags,

i just gave a very successful presentation on a slightly different view of delimited continuations. This may be of interest to this community.

Love to all,

--greg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SW
Seattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

--
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 | 3 Dec 20:11 2014
Picon

Emotional Support Group for Typesafe Maven Users

Does anyone know of a good emotional support group for people trying to use Maven with Typesafe projects such as Akka and Play?

I was thinking maybe there could a buddy/sponsor system, such as used in AA and other self help groups. Maybe there might be group sessions where people can talk about their trauma, especially by being constantly invalidated by comments such as "you should use the simple build tool SBT, cause, well you know, it's simple and easy to use."

Seriously though, is there a community of people who are successfully using Maven with Akka an Play projects? I would love to meet you.

I can see why people who have tried Maven naturally think "oh, its' too complicated, anyone can write a simple build tool that does what Maven does." Clearly they do not appreciate what Maven is or what it does. SBT and Gradle are two great examples of projects that attempted to do something more simple, but in the end, really don't measure up.

I personally think the Scala community would be been better served if more investment was made in developing better Scala build tools within the Maven framework. More and better plugins for Scala, Akka, Play, etc.  Better use of

http://books.sonatype.com/mcookbook/reference/sect-scala-script-inline.html
http://books.sonatype.com/mcookbook/reference/ch03s03.html

I don't know if there is a Scala template for writing Maven plugins (or mojos), but there should be.

The more I use SBT, the less I like it. It is not what I consider a serious build tool for build engineers, it is a toy or playground for Scala hackers who thrive on the abstruse. Don't get me wrong, I love Scala, but creating a build tool around .scala files just invites the use of chicken tracks and obscure overly concise cleverness that leads to one WTF experience after another. It is actually possible to write Scala code that you can reason about, but it just as easy to write Scala code that resembles APL, and reasoning about build engineering was clearly not a priority with the designers of SBT.

The Scala-IDE was a really great approach because it leveraged off of an existing IDE infrastructure such as Eclipse, rather than trying to write an IDE from scratch the way SBT does. I wish the Scala/Typesafe community had taken the same approach with build-tools.

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

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.

Gmane