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

61–70 of 192 posts

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

#61

Post by tomjupiter »

klyrs wrote: post #57
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…

> It should be this: > int* a; I must disagree... the following sends the wrong message the reader: int* a, b; Though I also agree that dereferencing is best without a space. Perhaps the correct suggestion is to not declare pointers and instances on the same line, but that's a convenience that many seem to enjoy

I think mariodiana is describing a hypothetical language where a and b would both be int-pointers in this case.

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

#62

Post by WalterBright »

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…

Ironically the article chose the syntax:

    class Id() {
Instead of the D syntax:

    class Id(T) {
Not using for template parameters eliminates all kinds of parsing problems.

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

#63

Post by estebank »

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

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 fire). The turbofish is another case where we now suggest the correct syntax, but there are many, many more.

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

#64

Post by ZoomZoomZoom »

WalterBright wrote: post #62
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…

Ironically the article chose the syntax: class Id () { Instead of the D syntax: class Id(T) { Not using for template parameters eliminates all kinds of parsing problems.

I don't see it being ironic. In Rust () is always a tuple, so if you see it that way it makes sense () isn't used for type declaration.

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

#65

Post by WalterBright »

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

Being parser-friendly is not at all the same thing as being user-friendly. The difficulty of writing parsers is way overblown.

One thing to avoid is depending on the existence of the symbol table to parse correctly. (C++ has this problem.) Needing a symbol table makes it hard for parsers like source code formatting and syntax highlighting.

Another is to avoid raw string literals that reach back and try to unwind the results of previous "phases of translation".

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

#66

Post by ncallaway »

downerending wrote: post #60
MaxBarraclough wrote: post #51

Earlier quoted context omitted.

> In 2020, not sure we should care that much about how hard compilers have to work to achieve this. That's not right. Long compile times are a real issue for some programming languages even today (Rust and C++). > Computers and software are here to support us--we're not here to support them. A false dichotomy, and not a perspective that offers any insight. Sometimes a low-level language is appropriate, and sometimes…

I'd consider compile time as part of the UI, so in that sense I think we agree. (If the compile is long because the implementation is poor, that needs to be fixed.) Not sure what you mean on the dichotomy. If someone says that a language needs to have X because that will make things simpler for the computer, I say that they are wrong. The goal, the only reasonable goal, is to make things better for humans.

> If the compile is long because the implementation is poor, that needs to be fixed

The compile time could be long because the implementation is poor. But it's also possible that the specific requirements do not allow for a significantly faster compile time.

That's why the requirements matter. They determine the space of possible implementations. If the requirements eliminate all "fast" implementations, then the resulting user experience will be poor because of slow compile times.

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

#67

Post by barrkel »

Animats wrote: post #12
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…

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…

Yeah, the easiest way to do it is return a different token type from the lexer for type names, which means the lexer looks up the symbol table when it sees identifiers.

Amusingly, the Delphi dialect of Pascal has an ambiguity in its grammar from how it made function pointers work:

    function g: Integer;
    // ...
    f(g);
Depending on the definition of f, this could be passing the function f by reference (as a function pointer), or passing the result of calling f.

Delphi looks at the argument type to resolve the ambiguity, but it stays awkward in overload scenarios, when there's a choice between Integer or function pointer arguments.

At some point around about 2009, I added the ability to specify explicitly that you want the call, to eliminate the ambiguity:

    f(g());

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

#68

Post by WalterBright »

tomjupiter wrote: post #61
klyrs wrote: post #57

Earlier quoted context omitted.

> It should be this: > int* a; I must disagree... the following sends the wrong message the reader: int* a, b; Though I also agree that dereferencing is best without a space. Perhaps the correct suggestion is to not declare pointers and instances on the same line, but that's a convenience that many seem to enjoy

I think mariodiana is describing a hypothetical language where a and b would both be int-pointers in this case.

To declare two pointers to int in C:

    int *a, *b;
In D:

    int* a, b;
The use of whitespace makes the distinction clear, although the parser doesn't care.

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

#69

Post by skybrian »

nitrobeast wrote: post #15

It is presented here that name before type is easier to read as a matter of fact. I’m not so sure. In math or languages where type info is optional, we often write “x = 5”. When type info is required, it is natural to evolve to “int x = 5”. Readers would naturally focus on the latter part. When we write “x: int = 5”, the type info is in the middle. We cannot skip it even when we just want to focus on the name and val…

If you have local type inference, an alternative would be "x = 5: int".

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

#70

Post by steveklabnik »

Gibbon1 wrote: post #58
MaxBarraclough wrote: post #51

Earlier quoted context omitted.

> In 2020, not sure we should care that much about how hard compilers have to work to achieve this. That's not right. Long compile times are a real issue for some programming languages even today (Rust and C++). > Computers and software are here to support us--we're not here to support them. A false dichotomy, and not a perspective that offers any insight. Sometimes a low-level language is appropriate, and sometimes…

C++ is stuck in this trap where because it's slow to compile, the compiler maintainers increase the amount of optimizations the compiler does to make it faster. Which of course makes the compiler even slower. Which motivates them to increase the amount of optimizations. Which makes the compiler yet slower. I feel part of the problem with rust is it doesn't have quick and dirty mode thats fast and a production ready m…

The checks are not the most expensive part of compiling Rust.
Post reply on HN