There's no meaningful whitespace in your example. You have a syntax error in the first example.
To get the effect you wanted in the you needed a `.`:
1> 2 + 2
1> .
4
The syntax error is indicated as being on line 2 (though not obviously on line 2) with the prefix to the error:
* <line number>: <syntax error information>
1> 2 + 2 2 + 2.
1> 2 + 2
1> ,2 + 2. ;; this is weird to do, but valid
4
Oh, that makes sense! Thanks to both you and moreoutput.
My argument is wrong then-- this isn't shockingly bad anything, just a little quirkiness.
I think part of it is that the shell is not the most forgiving of syntax errors, and Erlang doesn't always give the clearest syntax error description.
It's always been correct by line number for me, but I usually have to read that and the line above/below to understand what my actual errors are.
Re:A History of Erlang (2007)
by moreoutput on Monday April 06, 2020 @06:29PM
(#22798518)
What am I missing here? I see no meaningful white space when running the same logic. I would expect this from any language when expressions aren't properly terminated.
Eshell V10.4 (abort with ^G)
1> 2+2
1> 2+2.
* 2: syntax error before: 2
1> 2 + 2.
4
2>
Re:A History of Erlang (2007)
by hope-striker on Tuesday April 07, 2020 @12:54AM
(#22800441)
Yep, GP mentions in another comment that they misinterpreted the error.[0]
Anyway, Python replaces the prompt ">>> " with "... " if the input is mid-statement, and I suppose it would be nice if Eshell did the same thing.
This whole thread is going in my "Humility" file, not only did I misinterpret the error this one time, I've been messing around at the Erlang REPL putting a space after each command for absolutely no reason <headdesk>.
If you think that's bad, wait until you realize that even though people will fill threads talking about zig being a successor to C, it -purposefully- errors out on carriage returns and tabs! It is specifically built in that if you save a text file out of any windows editor without changing special settings, zig will error out. If you put in tabs, it will error out. Now trailing white space doesn't seem so bad.
what is this, 2009? If your language cares about it, Your code editor should automatically convert CRs and tabs as you type.
Every language in existence is able to deal with default windows files. Zig -intentionally- breaks on carriage returns and tabs. It went out of its way to not work.
I think that's a wise choice. The zig ecosystem doesn't need people that get hung up on that.
For example:
Note the trailing whitespace(!) after the last `2 + 2. `, necessary for the result to be printed.I was coming from Haskell which has its own very serious tooling and ergonomics problems. Trying Erlang made me realize things could be even worse. My internal model in my head of language designers/promoters is COMPLETELY wrong, I have absolutely no idea how people could spend time promoting languages with such strange tooling to a general audience with any expectation that it will work.[1]
[1] Not to say that these languages/tools aren't awesome. Trailing whitespace matters semantically absolutely not at all. But if you're trying to promote a language with meaningful trailing REPL whitespace to a general 2020 audience there is some terrible mismatch between your expectations and your actual chance of success.