Comment by gethly
2 days ago
Remove all of that noise.
Take this:
fn fib(n: i32) -> i32 {}
The (n: i32) can be just (n i32), because there is no benefit to adding the colon there.
The -> i32 can also be just i32 because, again, the -> serves no purpose in function/method definition syntax.
So you end up with simple and clean fn fib(n i32) i32 {}
And semicolons are an ancient relic that has been passed on to new languages for 80 fucking years without any good reason. We have modern lexers/tokenizers and compilers that can handle if you don't put a stupid ; at the end of every single effing line.
Just go and count how many of these useless characters are in your codebase and imagine how many keystrokes, compilation errors and wasted time it cost you, whilst providing zero value in return.
In a Hindley-Milner (or deriative) type system, types doesn't have to be explicit, making the number of arguments ambiguous here:
But even if they need to be written explicitly, type applications like `List a` would require syntax to disambiguate them.
Personally, I would like a language that pushes the programmer to write the types as part of a doc comment.
Also think about returning lambda's. Should it look like this?
Of course the IDE could help by showing the typographic arrows and other delineations, but as plaintext this is completely unreadable.
You still have to think about stuff like currying. You either delimit the line, or you use significant white space.
> Also think about returning lambda's. Should it look like this? > > fn foo(n i32) (i32 i32) {}
It should be
It will also allow future implementation of named returns, like in Go:
As for semicolon, that is needed only if you have inline expression:
Or inline block, like in Go:
But now consider returning a function with type¹
even if you leave out the latter type constraint, I think it is hard to avoid undecidable ambiguity.
You quickly get ambiguity due to type parameters / generics, functions as arguments, and tuples if you don't syntactically separate them.
Even if you your context-depended parser can recognize it, does the user? I agree that a language designer should minimize the amount of muscle damage, but he shouldn't forget that readability is perhaps even more critical.
____
1. Note, even if the parser can recognize this, for humans the '>' is confusing unless syntax highlighting takes care of it. One time it delimits a generic type argument, the other time it is part of '->'. This is also an argument for rendering these things as ligatures.
3 replies →
> The (n: i32) can be just (n i32), because there is no benefit to adding the colon there.
> The -> i32 can also be just i32 because, again, the -> serves no purpose in function/method definition syntax.
Well, there is, but it's more of a personal trait than a universal truth. Some human programmers (e.g. me) tend to read and parse (and even write, to some extent) source code more accurately when there is a sprinkle of punctuation thrown in into a long chain of nothing but identifiers and subtly nested parentheses. Some, e.g. you, don't need such assistance and find it annoying and frivolous.
Unfortunately, since we don't store the source code of our programs as binary AST blobs that could be rendered in a personalized matter, but as plain text instead, we have to accept the language designer's choices. Perhaps it actually has better consequences than the alternative; perhaps not.
the only reason why one might hold such an opinion is the lack of syntax highlighting.
What’s with all the periods, one at the end of each paragraph? Fully wasted.