Hacker News Reader

Comment by Izkata | Hacker News Reader

Strong disagreement here. "type ident" flows with the data during assignment, doesn't confuse the infix operators, and doesn't misuse ":" from a human-language standpoint.

For example:

  val x: String = "hello"

The type interrupts the flow of data from "hello" to x, so one thing that pops into mind is that this is typecasting the value to a string before storing it. Nope.

Another possibility I instinctively see this as is doing a comparison and assigning the result (either true or false in this case) to x. Nope.

And human-language wise, colon is "description: explanation" (or more generally: general to specific), which actually fits this syntax better:

  val String: x = "hello"

...and at that point, just remove the extraneous stuff:

  String x = "hello"

View on HN

> The type interrupts the flow of data from "hello" to x, so one thing that pops into mind is that this is typecasting the value to a string before storing it. Nope.

> Another possibility I instinctively see this as is doing a comparison and assigning the result (either true or false in this case) to x. Nope.

You can write it as

    val x = "hello" : String

if you prefer. In fact that's a great advantage of this syntax: any expression can be optionally ascribed with a type. If you write the type first then it becomes too intrusive (and too much like a typecast, which absolutely should be intrusive).

> And human-language wise, colon is "description: explanation"

True enough, but what other syntax would fit in postfix position? In human language we'd probably use commas ("Bob, chef"), but that seems a bit too ambiguous in a programming language.

If you're using immediate initialization, leave the type off entirely and let the compiler infer it.

I agree, though I could see the merit for a standalone declaration:

  val x: String
  x = "hello"

The type at this point is almost like a comment.

For declaration and assignment though, I agree that reading "ident: Type" is harder for me.

Perhaps an interesting idea would be to have the type at the end of the expression. Like so:

  val x = "hello": String

Essentially, you're making a type assertion on an expression. Since it's an assignment expression (the value of which would be the assigned variable) then it also type checks the variable.

Most statically typed languages don't even need the type assertion in a case like this, though. A literal has a definite type (hopefully), so the type of x can be inferred.

  val x = "hello"

Standalone declarations are the most important problem to solve here.

Yeah, type inference is preferred (and pretty common). I'm just saying that, if I had (or wanted to) set the type, at the end of the expression would be my preferred place.

But now it's difficult to declare that x is single assignment.

Not sure that's true. I'd I say:

  let x = "hello": String
  let x = "world": String

If 'let' is a keyword that implies single assignment, then problem is solved.

Alternatively, using pattern matching alarm Erlang would be even better:

  x = "hello": String //x is bound to "hello"
  x = "hello": String //equality check is successful
  x = "world": String //Error: values not equal

> Perhaps an interesting idea would be to have the type at the end of the expression. Like so:

> val x = "hello": String

Rust has had exactly this (so-called type ascription) for a while in nightly, but it's not stabilized yet due to some unresolved issues.

Good to know!

But a colon is also often used to indicate a mapping of names or categories to value. For instance:

  Breakfast: eggs and bacon
  Lunch: falafel sandwich
  Dinner: BBQ pork and slaw

The type of the variable is the "explanation" here.

  val x: String

"x, which is a String"

  val x: String = "hello"

"x, which is a String, is initialized with 'hello'"

What's the point of the 'val' keyword? It reminds me of Visual Basic's "Dim x As String".

val is immutable, var is mutable

Immutable, as opposed to var which declares a mutable variable.

Having a keyword for variable initialization makes parsing easier and less ambiguous. "let", "var", etc. are also used for this purpose, but I was going along with the example.

Your examples have the things on the right and the type on the left, and then used it to describe why examples on the left and [types] on the right makes sense...

If anything you've just argued that

String: x, y

is a preferable declaration style.

The point of the list isn't to say "eggs and bacon is a kind of breakfast", it's to say "breakfast is eggs and bacon". It's "name: details about name", not "type: instance".

Wouldn’t that argue in favor of

  val breakfast: “eggs and bacon” = String

and not

  val breakfast: String = “eggs and bacon”

My intention was solely to counter the idea that using ":" to mean "is" or "is a" is somehow inconsistent with written English. I don't think it's always necessary or even desirable to match the use of symbols in programming with English orthography, in any case.

The use of a declaration with initialization as the example here muddies the water. Whatever syntax you use has to work for uninitialized declaration of variables, function arguments, and structure members:

  val breakfast: String
  fun serveBreakfast(breakfast: String)
  struct MealPlan {
    breakfast: String
  }

Declaration with initialization just needs to be consistent with these.

I was going to say the same thing about meaning flow.

But here's an idea. The OP wants meaning to flow left to right for lambda declarations. Why not have assignment go that way too.

    "Hello" => x: string

Might work. Computer science pseudocode uses notation kind of like that.

Also, I understand now why Scala and Rust always seemed clunky to me.

> Computer science pseudocode uses notation kind of like that.

Does it? In my time at the university, assignments in pseudocode were usually written as

  x <- "Hello"

Reply on news.ycombinator.com