Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Language Design: Use 'ident: Type' not 'Type ident'

soc.me

Post reply on HN
Print view View original

101–110 of 192 posts

Re: Language Design: Use 'ident: Type' not 'Type ident'

#101

Post by saagarjha »

dirtydroog wrote: post #95
djur wrote: post #88

Earlier quoted context omitted.

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

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

Re: Language Design: Use 'ident: Type' not 'Type ident'

#102

Post by hinkley »

djur wrote: post #88
Izkata wrote: post #40

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…

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

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.

Re: Language Design: Use 'ident: Type' not 'Type ident'

#103

Post by [deleted] »

earthboundkid wrote: post #94
mariodiana wrote: post #50

Earlier quoted context omitted.

I was just thinking about pointer syntax today, and if you ask me, there are a lot of problems that could be avoided if language designers took a page out of Guido van Rossum's book and extend his idea of forced spacing. Take the first example you've given, and let's just talk about variable declaration: int* a; int * a; int *a; That's all the same. That's wrong. Obviously, you can write a lexer and parser that doesn…

A pointer to an int "should" be &int, not int*. That we use *, the dereference operator, to indicate pointers is wrong. * in a type means it's an address, but * in a value means it's not an address. That's nuts! Make it consistent and use & both places. If you need to have a distinction between refs and pointers, it should be that pointers are nullable refs: &int? or some such. Edit: How to escape asterisks in HN?

[deleted]

Re: Language Design: Use 'ident: Type' not 'Type ident'

#104

Post by hinkley »

lliamander wrote: post #78
Izkata wrote: post #40

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…

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…

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

Re: Language Design: Use 'ident: Type' not 'Type ident'

#105

Post by cyphar »

mariodiana wrote: post #50
TazeTSchnitzel wrote: post #8

A more practical reason as a language designer is that C and C++-style type-before-name syntax is a nightmare to lex and parse, as you can't tell whether A * B; is a multiplication or a variable declaration, or whether A D; is a two comparisons with a comma operator or a templated variable declaration, without first knowing the names of all declared types. This means in practice that you have to declare types before…

I was just thinking about pointer syntax today, and if you ask me, there are a lot of problems that could be avoided if language designers took a page out of Guido van Rossum's book and extend his idea of forced spacing. Take the first example you've given, and let's just talk about variable declaration: int* a; int * a; int *a; That's all the same. That's wrong. Obviously, you can write a lexer and parser that doesn…

People have been arguing about where the asterisk should be for a very long time. The main counter-argument to the construction you used is that multiple variable declaration immediately looks ugly given the current rules of C variable declaration:

    int* a,* b; // ??
And that's usually why most C style guidelines use

    int *a, *b;
Now, if we treated "int" as the full type name in the syntax then you get a much nicer result:

    int* a, b; // much nicer!
Though that does have its own tradeoffs. But that would require actually changing the C syntax, at which point you might as well make it the postfix syntax:

    var a, b int*;

Re: Language Design: Use 'ident: Type' not 'Type ident'

#106

Post by mhh__ »

dirtydroog wrote: post #93
klyrs wrote: post #76

Earlier quoted context omitted.

C is just riddled with mistakes and this one finally gelled with me. Python taught me that whitespace is great for syntax and, in this case, I'm quite convinced that it should be used more firmly in most languages.

I find the opposite, I can't stand it. Give me curly braces over arbitrary indentation any day.

I think a better (subjective of course) lesson might be to enforce a style.

I have been thinking about making a toy compiler (I wanted to write a borrow checker) that treats bad code as an error, solely aimed at numerical code - I have recently had "Scientific Programming in Python for physics etc." inflicted on me.

Slight tangent, but I think if Haskell enforced some kind of whitespace a la Python it would be much more approachable in real codebases (Haskell is usually quite readable if you are just translating mathematics into code but it - to me at least - feels dreadful as a productive language because of the way a lot of functions seem to be dumped onto into the text editor in a lot of the code I have read)

Re: Language Design: Use 'ident: Type' not 'Type ident'

#107

Post by thrtythreeforty »

lmkg wrote: post #46
Animats wrote: post #12

Earlier quoted context omitted.

It's a historical problem in C. Originally, C had only built-in types. Structs were declared with struct foo { int x; int y; }; which is easy to parse. Then came typedef. With user-defined types, foo*bar; isn't parseable with a LALR(1) parser until you've seen the definition of "foo". Even the ordinary case foo bar; needs more than one lookahead to parse. This is a headache for compilers, and a huge headache for anyt…

> Not sure about Rust Rust has made a point of being parser-friendly, to support tooling. The entire reason the turbofish :: exists is to avoid ambiguous grammar. (This operator seems to vex people, I don't get the hate.)

I love the turbofish so much, not because it looks nice in code or anything, but because the name is a bit of harmless fun that makes the language feel inviting.

Re: Language Design: Use 'ident: Type' not 'Type ident'

#108

Post by dllthomas »

mariodiana wrote: post #50
TazeTSchnitzel wrote: post #8

A more practical reason as a language designer is that C and C++-style type-before-name syntax is a nightmare to lex and parse, as you can't tell whether A * B; is a multiplication or a variable declaration, or whether A D; is a two comparisons with a comma operator or a templated variable declaration, without first knowing the names of all declared types. This means in practice that you have to declare types before…

I was just thinking about pointer syntax today, and if you ask me, there are a lot of problems that could be avoided if language designers took a page out of Guido van Rossum's book and extend his idea of forced spacing. Take the first example you've given, and let's just talk about variable declaration: int* a; int * a; int *a; That's all the same. That's wrong. Obviously, you can write a lexer and parser that doesn…

There's a perspective that doesn't seem to be noted yet, which is that

   int *f
is declaring that

   *f
will be an int.

This perspective addresses why the star belongs with the name, why it's star instead of ampersand, why you need to repeat the star for multiple variables, why the brackets goes after the name for arrays, and it will sort of get you where you need to go with function pointers (although there's an automatic promotion which means things will work at the call site that won't work for the type).

This isn't to say alternative constructions mightn't be a better choice in a new language, but it's much more parsimonious when considering C than memorizing a bunch of special cases.

Re: Language Design: Use 'ident: Type' not 'Type ident'

#110

Post by Ar-Curunir »

thom wrote: post #56
Ar-Curunir wrote: post #4

Earlier quoted context omitted.

I mean most programming languages put some sort of punctuation between names. Eg: function calls are punctuated by parens, imports are punctuated by `::` or `.`. The same should happen for types.

I think the vast majority of code that exists in the world today has at most one space between a variable and its type.

There’s a difference between “things that are implemented in popular programming languages” and “things that are implemented in most programming languages”
Post reply on HN