Hacker News Reader

Comment by gingerBill | Hacker News Reader

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

View on HN

> But I am using Oberon-07 as base, and I might deviate from it quite soon too.

I am curious about your thoughts on var parameters (i.e. mutable references), as in:

    proc increment(var x: int)
    begin
      x := x + 1
    end

    var i: int

    begin
      i := 10
      increment(i)  // i is now 11
    end

i also wonder about this concept; is there a programming language that has this behavior?

Ada, Nim, Pascal. I think C++ also offers it with a specific syntax.

Rust also offers it, but you need to specify it on the call side as well.

Fortran can do "in out" arguments to subroutines also.

Really nice project, well done.

I would say it's probably not necessary to explain what the connection between Titania and Oberon is in the README. It's probably evident to most people?

Alas, most people have memorized at most seven Shakespearean sonnets.

Supporting lowercase keywords and making (at least some) semicolons optional already makes Oberon much more attractive ;-)

And removing unnecessary keywords and modernizing it too. `[N]T` for arrays and `^T` for pointers, rather than `array N of T` and `pointer of T`. And supporting C++ style code `/*/` and `//`.

And as I develop this, I'll tweak it more so that people can actually understand without having to know the full histories of Pascals or Oberons or whatever.

I have also implemented these and other simplifications in my languages, and I don't think it makes them any less readable. Looking forward to seeing your final design.

Trying to eliminate semicolons by doing JS-style ASI is gross and complicates things unnecessarily. You can trivially change the parser/grammar so that the semicolons in import, var, procedure, etc. declarations just aren't required, and likewise with statements that end in "end". They'll still be necessary for statements comprising things like assignments and procedure calls, but for a teaching language who cares.

(Your grammar is missing a definition for proc_call, by the way.)

I only added that a few minutes ago, and it's a question of whether I should or not. This project is so goddamn new that I have not even decided anything. I was not expecting anyone posting this to HackerNews in the slightest.

Also this isn't JS-style ASI technically speaking, and it won't have any of the problems either. The syntax for this language is different enough that it won't be a problem. Procedures don't even return things.

I'm referring to the semicolon insertion described in the README as, "When a newline is seen after the following token kind, a semicolon is inserted".

> Procedures don't even return things

Oberon allows return values from functions (which are still declared with the PROCEDURE keyword). It looks like the same is true in Titania:

    proc_body = decl_sequence ["begin" stmt_sequence] ["return" expr] "end".

<https://github.com/gingerBill/titania/blob/085b7b5bcf7f06076...>

I'm curious what you're going to do with the code generator. Parsers are easy and can be completed in a day or two. Even with a reference implementation, however, it's the backend that's a slog.

I know Oberon does return things from certain procedures but I might not. I know the grammar allows for it but again, this is subject to change.

As for code generation, direct machine code to a Windows AMD64 PE executable.

Backend should not be that difficult because I am not working on anything complex nor optimizing. This won't be an optimizing compiler backend course.

Definitely wise not to choose "uranus" as the name. ;)

Reply on news.ycombinator.com