> 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.

This design decision makes compiler implementation easier and especially enables single-pass compilation. Later Oberon versions at least supported more than one declaration section in arbitrary order, but still no in-place declarations.

When I write the backend (this repo isn't even 24 hours old yet), you'll find out why variable declarations are at the top of a procedure. (Hint: it has something to do with the stack).

A nice side-effect of "variables at the top": you keep your functions short.

Wirth was obsessed with the idea of creating the absolutely minimal useful language, and many of his languages' warts come from that.

Variables are at the top because:

- you immediately see them (so, perhaps, easier to reason about a function? I dunno)

- the compiler is significantly simplified (all of Wirths' languages compile superfast and, if I'm not mistaken, all are single-pass compilers)

However, I feel that Wirth was overly dogmatic on his approaches. And "variables must always be at the top" is one of those.

That was the idea.

Please note the project isn't even 24 hours old yet.

But I am using Oberon-07 as base, and I might deviate from it quite soon too. But I won't be going in the direction of things like Oberon+ (which adds generic and OOP programming) or Micron which adds the entire type system necessary to interact with foreign code. I just wanted something to explain to people how to do tokenizing, parsing, semantic checking (not just basic types), and machine code generation, and this seemed like the best language to choose.

n.b. I know the name does comes from from the Voyager space probe, but I wanted to keep it directly related somehow, and Titania was the best fit. It's also a moon of Uranus, and there is a story relation to Oberon (Fairy King).

not Scotish sadly, AFAIK so: wowsers! kinda recall someone saying something about this?! \o/ yey

Is the language/project somehow related to Odin or its ecosystem, or is it completely independent?

If the latter, I wonder how you can manage another programming language alongside Odin — anyway, thank you and great respect for both!

Not surprising, it appeared in 1.3k github feeds of your followers.

I have teached Pascal 25 years ago. The idea was to teach the basic principles of programming (loops, variables, arrays, linked lists, sorting, etc.) without worrying about the technical details (C was too tricky, python was not there). Plus Pascal is quite simple and has very few pitfalls.

Once students where proficient in Pascal, we could introduce compiler classes and, when sufficiently advanced, show what the Pascal BNF grammar looked like. So students had a complete picture of a language. Pascal's BNF grammar is very simple.

Also, Pascal enforces strong program structures (BEGIN, END, PROCEDURE, FUNCTION, etc). which helps to frame practical work.

He's the author of Odin, so he has experience writing compilers, so he also wrote a toy compiler in his language as a fun weekend project I guess. Of course it's only a good learning resource for people familiar with Odin. I don't know much about Odin, but from glancing at the code it looks like there are some memory management related features that he's using, which would look uglier in other languages.

Oberon is a general-purpose programming language, not a DSL. Even though it is very minimal, you can still do quite a bit in it.

But the point of teaching compiler development is to teach people how to do the basic things from tokenizing, parsing, semantic checking, and code generation (directly to machine code).

I have found this is actually a skill most programmers don't even know how to do, especially just tokenizing and parsing, so I thought I'd use Oberon-07 as a base/inspiration for it.

n.b. at the time of this comment, the repo/project is not even 24 hours old yet.

The project is not even 24 hours old...

And I might plan on making this a recorded series of explaining how to make compilers from scratch with this language as a reference.

> the documentation mainly consists of the language grammar :)

It's a bit more than just the grammar, but I agree it's generally underspecified.

He is also the creator of Odin :)

from the grammar:

> pointer_type = "^" type.

Is your idea that that would always work? Like:

  s := "Hello world".; -- equivalent to "Hello world\n"

That would mess with dot syntax usually reserved for method calls. Like rust's "hello".to_string();