Having done a fair degree of programming in Wirthwhile languages, I think the only main design decision that I think was a mistake was the variables at the top.
I'm not sure of the value of seeing all of the variables used listed in one place, it has certainly led to me encountering a identifier scrolling up to determine the type then scrolling back down. When the variable is only used on a few consecutive lines it's just adding work to read and adding work to create. I daresay I have written harder to read code than I intended because I didn't want to go up and declare another variable for short term use. The temptation to inline the expression is always there, because you know what all the parts mean when you write it. It's only when you come back later that you get the regret.
It's possible it could be mitigated by defining something like (not sure if this is a valid grammar)
and bring in scoping on statement sequences. maybe call it stmt_block so that stmt_sequence can be a component that really is just a sequence of statements.
> I'm not sure of the value of seeing all of the variables used listed in one place
It means the compiler knows how much memory the function's activation frame will take and the offset into that for every variable before it encounters any code in the function.
Basically, it makes it easier to write a single-pass compiler. That was important in the 70s but is less important these days.
"Functions should always be short" is also one of those guidelines that people treat like a hard rule. There are occasions when a 100 line function is easier to read than 5 20 line functions, or god forbid 20 5 line functions.
Stop being overly dogmatic, it ALSO leads to worse code.
s := "Hello world".; -- equivalent to "Hello world\n"
Or only in `print`? If only in `print`, then you've suddenly made a context-sensitive grammar. And if the former, just use "Hello world\n" instead, since the tokenizer already supports that.
Having done a fair degree of programming in Wirthwhile languages, I think the only main design decision that I think was a mistake was the variables at the top.
I'm not sure of the value of seeing all of the variables used listed in one place, it has certainly led to me encountering a identifier scrolling up to determine the type then scrolling back down. When the variable is only used on a few consecutive lines it's just adding work to read and adding work to create. I daresay I have written harder to read code than I intended because I didn't want to go up and declare another variable for short term use. The temptation to inline the expression is always there, because you know what all the parts mean when you write it. It's only when you come back later that you get the regret.
It's possible it could be mitigated by defining something like (not sure if this is a valid grammar)
and bring in scoping on statement sequences. maybe call it stmt_block so that stmt_sequence can be a component that really is just a sequence of statements.> I'm not sure of the value of seeing all of the variables used listed in one place
It means the compiler knows how much memory the function's activation frame will take and the offset into that for every variable before it encounters any code in the function.
Basically, it makes it easier to write a single-pass compiler. That was important in the 70s but is less important these days.
A nice side-effect of "variables at the top": you keep your functions short.
"Functions should always be short" is also one of those guidelines that people treat like a hard rule. There are occasions when a 100 line function is easier to read than 5 20 line functions, or god forbid 20 5 line functions.
Stop being overly dogmatic, it ALSO leads to worse code.
Very nice project, I'm a big fan of implementing Wirthian languages to learn compilers.
Also, in true Wirth style, the documentation mainly consists of the language grammar :)
Clever name.
It'd be nice to see some discussion of the motivation for its departures from Oberon07.
Looking at your source, I was introduced to Odin -- now I want to hear a lot more about that.
He is also the creator of Odin :)
No pointers ?
from the grammar:
> pointer_type = "^" type.
A modest proposal…
Instead of having println() or it’s equivalent in your programming language, add a new special character that denotes a newline after a string:
print(“Hello world”.)
Is your idea that that would always work? Like:
Or only in `print`? If only in `print`, then you've suddenly made a context-sensitive grammar. And if the former, just use "Hello world\n" instead, since the tokenizer already supports that.I think the point is to add the correct end of line depending on OS.
That would mess with dot syntax usually reserved for method calls. Like rust's "hello".to_string();
Oberon doesn't have string methods (and people who opt not to parenthesize for cases like that deserve the punishment).