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

151–160 of 192 posts

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

#151

Post by Sharlin »

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…

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

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

#152

Post by [deleted] »

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…

[deleted]

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

#153

Post by Someone »

pansa2 wrote: post #49

> This means that the vertical offset of names stays consistent This is also an argument for using keywords of the same length for introducing a variable and a constant. If that’s desirable, it rules out the obvious choices `var` and `const`. Possibilities include `var` and `val`, which may be too similar-looking, and `var` and `let` - but are people used to (from JavaScript) `let` being mutable? Any other options?

“Let” is mutable in Basic, too, but the part of the population that is used to that is shrinking.

As to short, equal length options for ‘let’ and ‘val’: one could consider using punctuation. Forth uses colons instead of ‘fun’, and I think, in a concise language, one could get used to using, say, ‘!’ for immutable and ‘~’ for mutable. Unfortunately, they aren’t easy to type. An alternative could be to always assume immutability and only use ~ in the rare cases where one needs to mutate.

So, a simple

  foo = 3
or, if one wants to simplify parsing:

  = foo 3
introduces a new immutable variable, and

  ~ foo = 3
or

  ~ foo 3
a mutable one. If we allow leaving out spaces:

  ~foo 3
that starts to look like using sigils to indicate mutable state. I think that might be a good option in a mostly immutable language.

I think I would use Forth’s colon instead of ‘=‘. That would make ‘=‘ available for equality testing, allowing us to get rid of ‘==‘.

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

#154

Post by usrusr »

estebank wrote: post #63
lmkg wrote: post #46

Earlier quoted context omitted.

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

Do note that Rust the language is regular and easy to parse, but rustc the compiler actually performs bounded lookahead and contextual parsing on parse errors to detect common typos and invalid syntax that would otherwise be vexing to users. The nightly only type ascription : syntax is a good example because it crops up in several different contexts as a 1-substitution typo and used to be terrible (may it burn in a f…

Surely that's an example of how parser-friendly syntax empowers tooling? I imagine that it would be much harder to guess intention and fixes from lookahead and context if those were already necessary to make sense of correct code?

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

#156

Post by MaxBarraclough »

battery_cowboy wrote: post #143
tom_mellior wrote: post #135

Earlier quoted context omitted.

No, the claim was that metaprogramming made the grammar of C++ Turing complete.

Metaprogramming in C++ is TC, but it's not what makes C++ TC by itself.

You misunderstand. C++ is Turing-complete at compile time, due to template metaprogramming. This demonstrates that it isn't a context-free grammar.

This isn't true of all programming languages.

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

#157

Post by MaxBarraclough »

Ar-Curunir wrote: post #112
Gibbon1 wrote: post #85

Earlier quoted context omitted.

What is it then?

The codegen is. This is partially because the IR passed to LLVM is not the best, but it’s also not terrible.

Does Rust allow for fast unoptimised builds then? Perhaps I'd missed that.

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

#158

Post by tom_mellior »

battery_cowboy wrote: post #143
tom_mellior wrote: post #135

Earlier quoted context omitted.

No, the claim was that metaprogramming made the grammar of C++ Turing complete.

Metaprogramming in C++ is TC, but it's not what makes C++ TC by itself.

Yes, but it is the difference to other programming languages.

In C you cannot encode a Turing machine that is executed by the compiler at compile time. In Brainfuck you cannot encode a Turing machine that is executed by the compiler at compile time. In C++ you can encode a Turing machine that is executed by the compiler at compile time.

That is the difference we are discussing here.

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

#159

Post by htfu »

djur wrote: post #116
hinkley wrote: post #102

Earlier quoted context omitted.

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”

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

#160

Post by MaxBarraclough »

a1369209993 wrote: post #134
MaxBarraclough wrote: post #43

Earlier quoted context omitted.

I missed your mention of the 'most vexing parse' before writing this up, but for those not in the know, here's another fun quirk of C++ syntax: Declare a local named neko of type Kitten , passing a value to its constructor: Kitten neko(42); Declare a local named neko of type Kitten , without passing a value to its constructor: Kitten neko; Declare a function named neko with zero parameters and with return type Kitten…

And Ceiling Cat help you if you try to declare something like: Kitten neko(Felis ::catus); where catus may be either a typename or a variable depending which template instantiation you landed on. There's probably some way to say: Kitten neko(Felis ::value_of>::catus);

Beautifully terrible!
Post reply on HN