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 25 minutes ago [-]
A nice side-effect of "variables at the top": you keep your functions short.
jasperry 1 hours 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 5 hours ago [-]
Clever name.
It'd be nice to see some discussion of the motivation for its departures from Oberon07.
loumf 3 hours ago [-]
Looking at your source, I was introduced to Odin -- now I want to hear a lot more about that.
khaledh 3 hours ago [-]
He is also the creator of Odin :)
ruslan 3 hours ago [-]
No pointers ?
doug-moen 3 hours ago [-]
from the grammar:
> pointer_type = "^" type.
fijiaarone 3 hours 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 2 hours 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 2 hours ago [-]
That would mess with dot syntax usually reserved for method calls. Like rust's "hello".to_string();
cxr 2 hours ago [-]
Oberon doesn't have string methods (and people who opt not to parenthesize for cases like that deserve the punishment).
Rendered at 03:43:38 GMT+0000 (Coordinated Universal Time) with Vercel.
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”.)