5 ms·

The Titania Programming Language

105 points by MaximilianEmel 1y ago

__d 1y ago
Clever name. It'd be nice to see some discussion of the motivation for its departures from Oberon07.
ruslan 1y ago
No pointers ?
- doug-moen 1y ago
  from the grammar: > pointer_type = "^" type.
loumf 1y ago
Looking at your source, I was introduced to Odin -- now I want to hear a lot more about that.
- khaledh 1y ago
  He is also the creator of Odin :)
fijiaarone 1y 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”.)
- coderedart 1y ago
  That would mess with dot syntax usually reserved for method calls. Like rust's "hello".to_string();
  - cxr 1y ago
    Oberon doesn't have string methods (and people who opt not to parenthesize for cases like that deserve the punishment).
- Jtsummers 1y 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.
  - keithnz 1y ago
    I think the point is to add the correct end of line depending on OS.
    - kouteiheika 1y ago
      The correct end of line is always '\n'. Even Windows' Notepad supports it nowadays. I will gladly die on this hill. :P
Lerc 1y ago
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) stmt_sequence = {decl_sequence}. stmt {";" stmt} [";"]. 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 1y ago
  A nice side-effect of "variables at the top": you keep your functions short.
  - Turskarama 1y ago
    "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.
    - lenkite 1y ago
      There are occasions => There are only rare occasions.
  - mannschott 1y ago
    One would assume that, but in practice, the predominant style is not one of many short procedures. Instead it feels that there's a preference to just inline the code unless the resulting procedure will have more than one caller. For example, search for "PROCEDURE Scan" here: https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Texts.Mod.txt https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Texts... Control structures are deeply nested and this goes on for 64 (very dense) lines. The low line count but is an artifact of how Oberon is conventionally formatted. When reformatted to mimic the conventions of languages like C, Java or Python it works out to more than 120 lines. When I program in Oberon (recreationally) I tend to follow this style even though I would extract the same code into a separate method were I writing in Java.
jasperry 1y 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 :)
- gingerBill 1y ago
  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.
  - jasperry 1y ago
    Of course! It wasn't really a criticism, just a cheeky observation that the documentation for every Wirth-style language I've ever seen begins with the EBNF grammar. Though it's rare for a new language to do that today, I appreciate you continuing the tradition.
- Rochus 1y ago
  > the documentation mainly consists of the language grammar :) It's a bit more than just the grammar, but I agree it's generally underspecified.
geokon 1y ago
> teach compiler development with Not trying to be confrontational, genuinely curious.. but why is this an area where you'd want a DSL? My initial reaction is : When I'm learning a topic, the last thing I want to be worrying about is learning the ergonomics of a new language I'm guessing there's a good rational I'm missing it'd be nice to see some piece of compiler related code in this language that'd be ugly in a general purpose language
- gingerBill 1y ago
  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.
- wiz21c 1y ago
  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.
- rubystallion 1y ago
  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.
Panzerschrek 1y ago
We need more context. Why Odin's creator created yet another programming language?
- dismalaf 1y ago
  Why not? Lots of language designers create or work on more... Matz has Streem, SPJ is working on Epic's new language, the creator of Pony is working on MS' project Verona, probably lots of others. Doubt it will supplant Odin though, considering Odin's being used professionally.
- Jtsummers 1y ago
  The reason is given in the second sentence of the readme. > This is designed to be a language to teach compiler development with. That is, this is the language a student would implement a compiler for. It's in line with what you'll find for most undergraduate compiler courses in terms of complexity.
gingerBill 1y ago
This repo isn't even 24 hours old yet and it's on HackerNews... Just wow....
- ivanjermakov 1y ago
  Not surprising, it appeared in 1.3k github feeds of your followers.
- smartmic 1y ago
  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!
  - gingerBill 1y ago
    Completely independent of Odin (except being written in Odin). It's a plan to be a teaching tool to learn compiler development, that's it.
- kaichanvong 1y ago
  not Scotish sadly, AFAIK so: wowsers! kinda recall someone saying something about this?! \o/ yey
Rochus 1y ago
Remarkable that Bill is interested in a version of Oberon-07. It's even more minimalistic than the previous Oberon versions. I spent a lot of time with the original Oberon language versions and experimented with extensions to make the language more useful for system programming (e.g. https://oberon-lang.github.io/ https://oberon-lang.github.io/ and https://github.com/rochus-keller/oberon/ https://github.com/rochus-keller/oberon/). Eventually I had to give up backward compatibility to get to a language which I really consider suitable for system programming (and still minimal in the spirit of Oberon, see https://github.com/micron-language/specification/ https://github.com/micron-language/specification/ and https://github.com/rochus-keller/micron/ https://github.com/rochus-keller/micron/); it's still evolving though. If I get it right, Bill's language is considered for teaching purpose, which is also a goal of Wirth's languages, and for which these languages are well suited (especially for compiler courses). Also note that the name "Oberon" was not inspired by Shakespeare, but by the Voyager space probe's flyby and photography of Uranus's moons during the mid-1980s when the language was being developed (see https://people.inf.ethz.ch/wirth/ProjectOberon/PO.System.pdf https://people.inf.ethz.ch/wirth/ProjectOberon/PO.System.pdf page 12).
- gingerBill 1y ago
  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).
  - Rochus 1y ago
    Supporting lowercase keywords and making (at least some) semicolons optional already makes Oberon much more attractive ;-)
elcapitan 1y ago
@gingerBill Will there be accompanying blog posts or streams while you're building this?
- gingerBill 1y ago
  That was the idea.
Hendrikto 1y ago
Using his own Odin language to write another custom language. Next level.

__d 1y ago

Clever name. It'd be nice to see some discussion of the motivation for its departures from Oberon07.

ruslan 1y ago

No pointers ?

doug-moen 1y ago
from the grammar: > pointer_type = "^" type.

loumf 1y ago

Looking at your source, I was introduced to Odin -- now I want to hear a lot more about that.

khaledh 1y ago
He is also the creator of Odin :)

fijiaarone 1y 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”.)

coderedart 1y ago
That would mess with dot syntax usually reserved for method calls. Like rust's "hello".to_string();
- cxr 1y ago
  Oberon doesn't have string methods (and people who opt not to parenthesize for cases like that deserve the punishment).
Jtsummers 1y 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.
- keithnz 1y ago
  I think the point is to add the correct end of line depending on OS.
  - kouteiheika 1y ago
    The correct end of line is always '\n'. Even Windows' Notepad supports it nowadays. I will gladly die on this hill. :P

Lerc 1y ago

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) stmt_sequence = {decl_sequence}. stmt {";" stmt} [";"]. 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 1y ago
A nice side-effect of "variables at the top": you keep your functions short.
- Turskarama 1y ago
  "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.
  - lenkite 1y ago
    There are occasions => There are only rare occasions.
- mannschott 1y ago
  One would assume that, but in practice, the predominant style is not one of many short procedures. Instead it feels that there's a preference to just inline the code unless the resulting procedure will have more than one caller. For example, search for "PROCEDURE Scan" here: https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Texts.Mod.txt https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Texts... Control structures are deeply nested and this goes on for 64 (very dense) lines. The low line count but is an artifact of how Oberon is conventionally formatted. When reformatted to mimic the conventions of languages like C, Java or Python it works out to more than 120 lines. When I program in Oberon (recreationally) I tend to follow this style even though I would extract the same code into a separate method were I writing in Java.

jasperry 1y 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 :)

gingerBill 1y ago
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.
- jasperry 1y ago
  Of course! It wasn't really a criticism, just a cheeky observation that the documentation for every Wirth-style language I've ever seen begins with the EBNF grammar. Though it's rare for a new language to do that today, I appreciate you continuing the tradition.
Rochus 1y ago
> the documentation mainly consists of the language grammar :) It's a bit more than just the grammar, but I agree it's generally underspecified.

geokon 1y ago

> teach compiler development with Not trying to be confrontational, genuinely curious.. but why is this an area where you'd want a DSL? My initial reaction is : When I'm learning a topic, the last thing I want to be worrying about is learning the ergonomics of a new language I'm guessing there's a good rational I'm missing it'd be nice to see some piece of compiler related code in this language that'd be ugly in a general purpose language

gingerBill 1y ago
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.
wiz21c 1y ago
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.
rubystallion 1y ago
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.

Panzerschrek 1y ago

We need more context. Why Odin's creator created yet another programming language?

dismalaf 1y ago
Why not? Lots of language designers create or work on more... Matz has Streem, SPJ is working on Epic's new language, the creator of Pony is working on MS' project Verona, probably lots of others. Doubt it will supplant Odin though, considering Odin's being used professionally.
Jtsummers 1y ago
The reason is given in the second sentence of the readme. > This is designed to be a language to teach compiler development with. That is, this is the language a student would implement a compiler for. It's in line with what you'll find for most undergraduate compiler courses in terms of complexity.

gingerBill 1y ago

This repo isn't even 24 hours old yet and it's on HackerNews... Just wow....

ivanjermakov 1y ago
Not surprising, it appeared in 1.3k github feeds of your followers.
smartmic 1y ago
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!
- gingerBill 1y ago
  Completely independent of Odin (except being written in Odin). It's a plan to be a teaching tool to learn compiler development, that's it.
kaichanvong 1y ago
not Scotish sadly, AFAIK so: wowsers! kinda recall someone saying something about this?! \o/ yey

Rochus 1y ago

Remarkable that Bill is interested in a version of Oberon-07. It's even more minimalistic than the previous Oberon versions. I spent a lot of time with the original Oberon language versions and experimented with extensions to make the language more useful for system programming (e.g. https://oberon-lang.github.io/ https://oberon-lang.github.io/ and https://github.com/rochus-keller/oberon/ https://github.com/rochus-keller/oberon/). Eventually I had to give up backward compatibility to get to a language which I really consider suitable for system programming (and still minimal in the spirit of Oberon, see https://github.com/micron-language/specification/ https://github.com/micron-language/specification/ and https://github.com/rochus-keller/micron/ https://github.com/rochus-keller/micron/); it's still evolving though. If I get it right, Bill's language is considered for teaching purpose, which is also a goal of Wirth's languages, and for which these languages are well suited (especially for compiler courses). Also note that the name "Oberon" was not inspired by Shakespeare, but by the Voyager space probe's flyby and photography of Uranus's moons during the mid-1980s when the language was being developed (see https://people.inf.ethz.ch/wirth/ProjectOberon/PO.System.pdf https://people.inf.ethz.ch/wirth/ProjectOberon/PO.System.pdf page 12).

gingerBill 1y ago
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).
- Rochus 1y ago
  Supporting lowercase keywords and making (at least some) semicolons optional already makes Oberon much more attractive ;-)

elcapitan 1y ago

@gingerBill Will there be accompanying blog posts or streams while you're building this?

gingerBill 1y ago
That was the idea.

Hendrikto 1y ago

Using his own Odin language to write another custom language. Next level.