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.
foldl2022 · 51m ago
A nice side-effect of "variables at the top": you keep your functions short.
jasperry · 1h ago
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 :)
__d · 5h ago
Clever name.
It'd be nice to see some discussion of the motivation for its departures from Oberon07.
loumf · 3h ago
Looking at your source, I was introduced to Odin -- now I want to hear a lot more about that.
khaledh · 3h ago
He is also the creator of Odin :)
ruslan · 3h ago
No pointers ?
doug-moen · 3h ago
from the grammar:
> pointer_type = "^" type.
fijiaarone · 3h ago
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”.)
Jtsummers · 2h ago
Is your idea that that would always work? Like:
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.
coderedart · 2h ago
That would mess with dot syntax usually reserved for method calls. Like rust's "hello".to_string();
cxr · 2h ago
Oberon doesn't have string methods (and people who opt not to parenthesize for cases like that deserve the punishment).
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.Also, in true Wirth style, the documentation mainly consists of the language grammar :)
It'd be nice to see some discussion of the motivation for its departures from Oberon07.
> pointer_type = "^" type.
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”.)