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

▲ gingerBill 2 days ago | parent [-]

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.

▲ cxr a day ago | parent | next [-]

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

▲ gingerBill a day ago | parent [-]

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.

▲ cxr a day ago | parent [-]

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.

	▲	gingerBill a day ago \| parent [-]
		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.

▲ Rochus 2 days ago | parent | prev [-]

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.