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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Simon Ochsenreither-3
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.)

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

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


2016-01-21 15:46 GMT+01:00 Simon Ochsenreither <[hidden email]>:
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.)

--
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

Simon Ochsenreither-3
Maybe I should change the question instead... :-)

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

Simon Ochsenreither-3
In reply to this post by Dennis Haupt
val X = 5 instead

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

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Aw: Re: [scala-debate] FAQ: Why does Scala use "i: Int" syntax instead of "Int i"?

Dennis Haupt-2
yes, in scala it is called val
 
Gesendet: Donnerstag, 21. Januar 2016 um 17:02 Uhr
Von: "Simon Ochsenreither" <[hidden email]>
An: scala-debate <[hidden email]>
Cc: [hidden email]
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;

 

--
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@....
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Aw: Re: [scala-debate] FAQ: Why does Scala use "i: Int" syntax instead of "Int i"?

Dennis Haupt-2
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" <[hidden email]>
An: "Simon Ochsenreither" <[hidden email]>
Cc: scala-debate <[hidden email]>, [hidden email]
Betreff: Aw: Re: [scala-debate] FAQ: Why does Scala use "i: Int" syntax instead of "Int i"?
yes, in scala it is called val
 
Gesendet: Donnerstag, 21. Januar 2016 um 17:02 Uhr
Von: "Simon Ochsenreither" <[hidden email]>
An: scala-debate <[hidden email]>
Cc: [hidden email]
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;

 

--
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 [hidden email].
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@....
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Re: [scala-debate] FAQ: Why does Scala use "i: Int" syntax instead of "Int i"?

Simon Ochsenreither-3

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?

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Re: [scala-debate] FAQ: Why does Scala use "i: Int" syntax instead of "Int i"?

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 <[hidden email]>:

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?

--
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Re: [scala-debate] FAQ: Why does Scala use "i: Int" syntax instead of "Int i"?

Adriaan Moors-5
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")


On Thu, Jan 21, 2016 at 11:15 AM, Dennis Haupt <[hidden email]> wrote:
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 <[hidden email]>:

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?

--
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 [hidden email].
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Re: [scala-debate] FAQ: Why does Scala use "i: Int" syntax instead of "Int i"?

Simon Ochsenreither-3
In reply to this post by Dennis Haupt
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

?

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

Russ P.
In reply to this post by Dennis Haupt
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.


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


2016-01-21 15:46 GMT+01:00 Simon Ochsenreither <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="0CHBYt6LAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">simon.och...@...>:
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.)

--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="0CHBYt6LAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">scala-debate...@googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

Erik Bruchez-2
In reply to this post by Simon Ochsenreither-3

On Thu, Jan 21, 2016 at 6:46 AM, Simon Ochsenreither <[hidden email]> wrote:
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.)

--
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

Russ P.
In reply to this post by Simon Ochsenreither-3
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.

On Thursday, January 21, 2016 at 6:46:51 AM UTC-8, Simon Ochsenreither wrote:
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.)

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

Rex Kerr-2
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

On Thu, Jan 21, 2016 at 11:50 AM, Russ P. <[hidden email]> wrote:
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.


On Thursday, January 21, 2016 at 6:46:51 AM UTC-8, Simon Ochsenreither wrote:
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.)

--
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

Lukas Rytz-2
In reply to this post by Simon Ochsenreither-3
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.



On Thursday, January 21, 2016 at 3:46:51 PM UTC+1, Simon Ochsenreither wrote:
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.)

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Re: [scala-debate] FAQ: Why does Scala use "i: Int" syntax instead of "Int i"?

Kevin Wright-3
In reply to this post by Simon Ochsenreither-3


On 21 January 2016 at 19:23, Simon Ochsenreither <[hidden email]> wrote:
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

?


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?

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Re: [scala-debate] FAQ: Why does Scala use "i: Int" syntax instead of "Int i"?

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


On 22 January 2016 at 15:38, Kevin Wright <[hidden email]> wrote:


On 21 January 2016 at 19:23, Simon Ochsenreither <[hidden email]> wrote:
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

?


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?

--
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

Russ P.
In reply to this post by Rex Kerr-2

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.

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

Simon Ochsenreither-3

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?

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

Russ P.


On Saturday, January 23, 2016 at 1:06:09 AM UTC-8, Simon Ochsenreither wrote:

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?


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) = ???
  }


--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
12