FAQ: Why does Scala use "i: Int" syntax instead of "Int i"?

[Simon Ochsenreither]

Proposed text:
========================================

While both syntactic approaches seem to be roughly equivalent on a cursory look, the advantages become clear when investigating how the syntax scales to larger examples.

Instead of i: Int and Int i, let's have a look at a generic method definition and its usage

class Bar[T](t: T) {
  def foo[S, T](s: S): T = ???; foo[Int, String](42)
}

to discover some desirable properties:

1. consistency in declarations like classes, methods, ...:
   Regardless of whether we define a class or a method, the ordering is the same: keyword – name – type parameters – value parameters – body
2. consistency between declaration and usage:
   the invocation of foo mirrors the declaration of foo – you just supply an argument to every parameter
3. declaration before use: the type variable name is introduced before it is used.
4. clear nesting/scoping: It should be obvious to the reader to which type variable a type parameters refers to.
   

If we check alternative syntactic approaches against these properties, we will see that all of them fail at least one of these properties:

class Bar[T](T t) { – or – class [T] Bar(T t) {
  [S, T] T foo(S s) = ???  // fails (1) and (2)
}

class Bar[T](T t) {
  T foo[S, T](S s) = ???  // fails (3) and (4): T is used before it is defined ... or does foo's return type refer to the T of the class?
}

Scala's approach provides consistency, reduces the mental complexity and let's users treat type parameters like the value parameters they already know: A method can have zero or more value parameter lists and zero or one type parameter lists.

========================================
Opinions? (I know that the wording around type variable, type parameter is not quite right ... need to fix that.)

[Dennis Haupt]

type inference.

instead of 

val x: X = 5

you can write 

val x = 5

and it is clear what you mean if the type is optional

but if the type comes first

val X x = 5

you could write

val X = 5 instead

it is now ambiguous. did you want to create a constant X? is your naming convention weird? did you intend to create a variable of type X but made a typo, got coffe and forgot about the little x?

to make it clear, you are always forced to write both type & name instead of just the name when the type is easy to infer

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Simon Ochsenreither]

Maybe I should change the question instead... :-)

[Simon Ochsenreither]

val X = 5 instead

Well, languages could just have some keyword like "auto" instead of the type name: auto x = 5;

[Dennis Haupt]

yes, in scala it is called val

 

Gesendet: Donnerstag, 21. Januar 2016 um 17:02 Uhr
Von: "Simon Ochsenreither" <simon.och...@gmail.com>
An: scala-debate <scala-...@googlegroups.com>
Cc: simon.och...@gmail.com
Betreff: Re: [scala-debate] FAQ: Why does Scala use "i: Int" syntax instead of "Int i"?

val X = 5 instead

Well, languages could just have some keyword like "auto" instead of the type name: auto x = 5;

 

--

[Dennis Haupt]

ah, you meant it another way. 

i meant, the point of type inference is to skip the type info instead of spamming it or a less useful placeholder everywhere

 

Gesendet: Donnerstag, 21. Januar 2016 um 17:06 Uhr
Von: "Dennis Haupt" <h-s...@gmx.de>
An: "Simon Ochsenreither" <simon.och...@gmail.com>
Cc: scala-debate <scala-...@googlegroups.com>, simon.och...@gmail.com
Betreff: Aw: Re: [scala-debate] FAQ: Why does Scala use "i: Int" syntax instead of "Int i"?

[Simon Ochsenreither]

i meant, the point of type inference is to skip the type info instead of spamming it or a less useful placeholder everywhere

Couldn't one argue that val/var is that placeholder in Scala?

[Dennis Haupt]

yes, but it has more functions. without it, is

x = 5 

a declaration of x, or do you change the value of x? how can you prevent an accidential creation of a new var/val?

what happens in case of nested constructs? will name shadowing become impossible?

2016-01-21 20:12 GMT+01:00 Simon Ochsenreither <simon.och...@gmail.com>:

i meant, the point of type inference is to skip the type info instead of spamming it or a less useful placeholder everywhere

Couldn't one argue that val/var is that placeholder in Scala?

--

[Adriaan Moors]

Type ascription uniformly adds type information to declarations and expressions. (The latter can be useful for clarification in more complex expressions or to diagnose type errors.)

val x = "1"

val x: String = "1"

"1"

"1": String

I find this much more regular than

auto x = "1"

String x = "1"

"1"

((String) "1")

[Simon Ochsenreither]

Yes, but isn't the issue what's better about

val x: Int = 1
val y = 1

compared to

Int x = 1
auto x = 1

?

[Russ P.]

On Thursday, January 21, 2016 at 7:04:12 AM UTC-8, Dennis Haupt wrote:

type inference.

instead of 

val x: X = 5

you can write 

val x = 5

and it is clear what you mean if the type is optional

but if the type comes first

val X x = 5

you could write

val X = 5 instead

Why did you drop the colon? Why not

val X: x = 5

This actually makes more sense to me because the assignment is to the value x, not the type X. And you can still have type inference and write simply

val x = 5

as we can now. To my way of thinking, it makes more sense to use "type: value" rather than "value: type". On a form, you don't see "Dennis: name", you see "name: Dennis".

The original poster dropped the colon too. Why? That distorts the comparison.

At one time I considered suggesting a compiler option to allow the "type: value" syntax as an alternative syntax, but I never followed through with it. I still think it might be worth doing if it could be done without too much effort.

[Erik Bruchez]

Anecdotally, Swift follows the same syntax:

    https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/swift/grammar/type-annotation

-Erik

--

[Russ P.]

Simon: Just to follow up on my earlier post, I suggest you do the comparison again using syntac of the form "Int: i" instead of "int i". In other words, don't drop the colon.

[Rex Kerr]

Russ, do you know of any language that uses that (or equivalent) syntax?  I think the point is to give comparisons to things people already know, not to comprehensively survey syntax space and show that a: A is the best possible.

  --Rex

--

[Lukas Rytz]

the regular `def id` / `val id` syntax is very useful when browsing code in an editor without semantic info (such as github, or a simple text editor).

it's much easier to find a method definition site.

[Kevin Wright]

But that’s not the issue!

If you’re writing C, very low-level, everything’s a primitive, etc, etc then there’s not so much difference between the two styles.

The issue is when you start making a real-world comparison instead of using such unrealistically trivial examples:

val x: Int :: String :: Set[String] :: HNil = myFirstFunc(param1, param2)

val y: Map[Int, List[Wibble]] = mySecondFunc(param1, param2)

val z: Agent[BigInteger] = myThirdFunc(param1, param2)

vs

Int :: String :: Set[String] :: HNil m = myFirstFunc(param1, param2)

Map[Int, List[Wibble]] n = mySecondFunc(param1, param2)

Agent[BigInteger] p = myThirdFunc(param1, param2)

Now, quickly, at a glance… what are the names of the important variables that I just declared in the second block?

[Paul Hudson]

Also, there's more going on with "auto" than has been shown so far

val is not just saying "please infer the type". It's also saying what kind of thing I'm declaring.

> Int x = 1

> auto x = 1

How do I declare a var if "auto" means "val"?

What about defs? What would be the syntax for "defs" with and without return-type type inference?

Paul

[Russ P.]

On Thursday, January 21, 2016 at 1:03:11 PM UTC-8, Rex Kerr wrote:

Russ, do you know of any language that uses that (or equivalent) syntax?  I think the point is to give comparisons to things people already know, not to comprehensively survey syntax space and show that a: A is the best possible.

Rex: No, I am not aware of any language that uses the syntax that I am proposing. And I realize that the original idea of this thread was to explain why Scala syntax is what it is, not to debate it.

However, you can count me among the unconvinced that this particular aspect of the syntax was the best choice. I'm used to it now, but when I first started using Scala, I had a hard time accepting the fact that I had to write

val x: Int = 5

rather than

val Int: x = 5

The latter just seems more logical to me because 5 is being assigned to x, not to Int. And the "x = 5" part is consistent with what would appear with type inference:

val x = 5

For functions it should be

def Int: someFunction(...) = ...

rather than

def someFunction(...): Int = ...

I have actually considered writing my own little pre-processor to reverse the order just for fun, but it wouldn't be of much value if I was the only one who used it. As I said earlier, I would like to see a compiler option to reverse the order if it could be done without too much effort.

[Simon Ochsenreither]

def Int: someFunction(...) = ...

rather than

def someFunction(...): Int = ...

I have actually considered writing my own little pre-processor to reverse the order just for fun, but it wouldn't be of much value if I was the only one who used it. As I said earlier, I would like to see a compiler option to reverse the order if it could be done without too much effort.

How would you deal with the shortcomings/issues mentioned in the first post?

[Russ P.]

I would write your example as

 class Bar[T](T: t) {

  def T: foo[S, T](S: s) = ???

  }

or perhaps even

 class [T] Bar(T: t) {

  def [S, T] T: foo(S: s) = ???

  }

[Nick Stanchenko]

Russ,

On Saturday, January 23, 2016 at 2:52:12 AM UTC, Russ P. wrote:

The latter just seems more logical to me because 5 is being assigned to x, not to Int. And the "x = 5" part is consistent with what would appear with type inference:

Applying the same logic, one can say that “def Int: x(Int: y) = y” looks like you are defining Int, not x ;)

I would also say that “class X[A]” makes more sense than “class [A] X”, because type parameters are parameters. “List[String]” reads nicely as “List of String”.

Nick

[Russ P.]

Nick: Yes, I agree that List[String] is more natural than [String]List, so nix that idea.

But I still think that 

val Int: x = 3

def Int: aFunction = 4

makes more sense than

val x: Int = 3

def aFunction: Int = 4

Why? Because x is a specific instance of Int. You don't see something like this on a form:

John: FirstName

Doe: LastName

Instead, you see this:

FirstName: John

LastName: Doe

The more specific information follows the comma rather than preceding it. A programming language is not required to be consistent with natural language, of course, but we might as well make it as consistent as possible unless a good reason exists to do otherwise.

I think I could write a fairly simple pre-processor to reverse the order and thereby invent my own dialect of Scala. The problem, of course, is that it wouldn't be of much value unless I could figure out how to make it work seemlessly with sbt, eclipse, and other IDEs. The other problem is that if it ever actually caught on, it would cause confusion whenever anyone is working on someone else's code and forgets which convention is in use.

[Nick Stanchenko]

Russ,

I would argue that an analogy with natural language can be twisted either way. In my mind, “FirstName: John” rather corresponds to the assigmnent part: “firstName = "John"”. The type is more of a clarification than a label, as in “Steve (label), my colleague (type ascription), is an engineer (definition)”. Now, one can of course also say “My colleague Steve is an engineer”, so both versions are perfectly valid. However in speech we choose one or the other based on what information needs to be emphasized. When you declare a binding, it seems reasonable to emphasize the label rather than the type, hence the preference for the former version.

Nick

--
You received this message because you are subscribed to a topic in the Google Groups "scala-debate" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-debate/SA6yJR8MTAk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-debate...@googlegroups.com.

[Rex Kerr]

Given that types can be inferred, I prefer putting the type information later since whatever is first is more prominent, and usually you care at least as much what the variable is named as you care what its type is.  (If you don't know your variable/method name, you can't use it!)

So that suggests to me that a postfix form like

  val x: Int = 5

  val x Int = 5

  val x [Int] = 5

is the way to go.  It also has nicer ergonomics for methods where you need to care about return type more than anything else for most methods, and there it is right at the end next to where you're writing code that's going to return that type:

  def foo(y: Int): Int = y+5
                    ^     ^
                    |     |

      it should be Int   and it is!

Now, for variables alone the colon is strictly optional in that the parsing is unambiguous even if it is omitted.  However, for expressions, you need some way to indicate that you're trying to perform a type ascription, and if you allow singleton objects with the same names as classes (as Scala does), simply stating the name at the end is not clear.

So this leaves us with things like : Int and [Int].

Personally I like the idea of having type-world mirror value-world more closely, so I'd argue that

    def foo[A](xs: List[A]): Int = ???

would be more regular as:

    def foo[val A](xs [List(A)]) [Int] = ???

but since regularity does not always aid readability, I do not mind the irregularity of Scala syntax much.

(I do mind that you can't do stuff like [val A; val B; val C = A & B], but that's an orthogonal issue.)

  --Rex

--

[Rex Kerr]

On Sun, Jan 24, 2016 at 2:15 PM, Rex Kerr <ich...@gmail.com> wrote:

(I do mind that you can't do stuff like [val A; val B; val C = A & B], but that's an orthogonal issue.)

I should clarify--you can ask for three types, A, B, and the intersection thereof; it's called

  [A, B, C <: A with B]

but what I mind is that the syntax is too unlike the value-manipulation syntax, so you have to keep two languages in mind all the time when doing type-work (instead of one language, with the API for operations on type-values).

  --Rex

 

[William Harvey]

The "i: Int" syntax that Scala uses is consistent with the notation used to denote judgments in type theory.  I'm not sure if that is advantageous in any way, but it could be considered interesting.

[Craig Tataryn]

My two cents with respect to Functions would be to draw attention to their three most important attributes: Arity, Parameter Type(s) and Return Type. A syntax in which those three features are clearly stated will promote higher readability.

Craig.

--

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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Craig Tataryn

blog: http://tataryn.net
podcast: http://www.basementcoders.com/
irc: ThaDon on freenode #basementcoders
twitter: @craiger

[som-snytt]

I'm pretty sure Scala syntax was devised to make it possible to migrate from Java but impossible to go back again.

I can't even grep for definitions in the Java codebase at work. It makes me miss ctags. Yes, it makes me fire up an IDE.