> 1. Names are more important than types
I can't really agree with this at all. With type aliasing the new typename can render the variable name pretty much redundant.
Language Design: Use 'ident: Type' not 'Type ident'
91–100 of 192 posts
Re: Language Design: Use 'ident: Type' not 'Type ident'
#92A 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…
On the other hand doesn’t forward declaration make sense? The code is declaring it depends on the forward declaration defined “somewhere else”. In a sense it is documenting the the classes/structs better.
Re: Language Design: Use 'ident: Type' not 'Type ident'
#93Earlier quoted context omitted.
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.
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.
Re: Language Design: Use 'ident: Type' not 'Type ident'
#94A 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…
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?Re: Language Design: Use 'ident: Type' not 'Type ident'
#95Strong 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'"
What's the point of the 'val' keyword? It reminds me of Visual Basic's "Dim x As String".
Re: Language Design: Use 'ident: Type' not 'Type ident'
#96Language Design: This stuff doesn't matter that much. Focus on more important things. Syntax isn't unimportant, but don't waste energy on trivial matters like these. Just pick something and people will get used to it. Focus on the semantics of your language - that's what really matters.
>Syntax isn't unimportant #104#101#108#108#111,[Space]world![Space][Space][Tab][Space][Space][Tab][Space][Space][Space][LF] [Tab][LF][Space][Space] [Space][Space][Space][Tab][Tab][Space][Space][Tab][Space][Tab][LF] [Tab][LF][Space][Space] [Space][Space][Space][Tab][Tab][Space][Tab][Tab][Space][Space][LF] [Tab][LF][Space][Space] [Space][Space][Space][Tab][Tab][Space][Tab][Tab][Space][Space][LF] [Tab][LF][Space][Space]…
Found the python programmer!
Re: Language Design: Use 'ident: Type' not 'Type ident'
#97Earlier 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?
I’ve had luck with not putting something directly after the asterisk.
Re: Language Design: Use 'ident: Type' not 'Type ident'
#98Earlier 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".
val is immutable, var is mutable
Re: Language Design: Use 'ident: Type' not 'Type ident'
#99Earlier quoted context omitted.
The grammar of C++ is not a context-sensitive grammar. It's Turing-complete, on account of its template metaprogramming capabilities. I'd be very surprised if Java's grammar were context-free. Do you have a source for this? I wasn't able to find one with a quick search.
It's Turing complete because it could simulate a Turing machine, not because of metaprogramming. The language brainfuck is Turing complete, for example.
Checking if a Brainfuck program is well formed (i.e. can be run) is a linear time operation. In C++ this can take forever. They have different complexities.
Re: Language Design: Use 'ident: Type' not 'Type ident'
#100Earlier 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?
I think you may be right, &int would be better than int*.
I did not want to stray too far from what C does now, for the sake of argument. I just wanted to say that the ambiguity in C is often because it's so loosey-goosey with whitespace.