1. 9

OBNC is a compiler for Niklaus Wirth’s programming language Oberon. It implements the latest version of the language from 2016. OBNC translates source code written in Oberon to the lower-level programming language C.

  1.  

  2. 3

    Still a cool language because of its simplicity and compilation speed (it influenced Go but is much simpler), its syntax is heavily dated though. I sometimes rewrite a code fragment from another language in Oberon (using OBNC) for educational purposes, if I am able to express it in Oberon and get the compiler to accept it, I feel that I truly understand it.

    1. 3

      I always thought a good project for students was to make an Oberon with C-like syntax. Keep safety in by default with “unsafe” keyword to turn it off in modules or blocks. Compile to assembly for full experience, to LLVM to learn that, or to vanilla C for use of many compilers. Also, give it macros. Every system language needs macros since they can solve so many problems. Gotta use them sparingly and carefully for code readability but some times they’re best solution.

      1. 2

        Also, give it macros. Every system language needs macros since they can solve so many problems. Gotta use them sparingly and carefully for code readability but some times they’re best solution.

        Definitely a good exercise for learning to code and navigate the code of a real world compiler.

        But, while I use C macro whenever a call seems as an unjustified waste of resources and I am not a macro detractor at all, I think that the whole point of Wirth’s work with Oberon design would be completely lost in the translation to a language with macros.

        Lisps apart, macros (and metaprogramming in general) are a form of code generation that could be moved outside the language. Apparently they are embedded in the language for convenience, to reduce the complexity of the build process, but this let a whole branch of code generation techniques unexplored.

        1. 2

          “Apparently they are embedded in the language for convenience, to reduce the complexity of the build process, but this let a whole branch of code generation techniques unexplored”

          People explored all kinds of methods. DSL’s for many languages were external. LISP’s were among few to internalize them. They maintained an advantage of consistency over the rest.

          1. 1

            Well I was not thinking about DSLs that serve specific purposes.

            By metaprogramming I was referring to those tools, such as macros, C++/Haskell templates, C# generics and so on, that basically generate code that is later compiled (either on binary generation or by a JIT compiler in the VM).

            Such preprocessing is usually integrated in the compiler suite (even in Lisp, where expansion occurs on read, if I remember correctly), and consequently integrated in the language.

            I’ve never seen people writing code in X to generate code in X.
            My insight is that this would be the Oberon approach to metaprogramming… but I have no proof this is what Wirth intended.

            Also this might be a selection bias or plain ignorance on my part.

            Do you have any example to share?

            1. 3

              I had some stashed links on metaprogramming and reflection in Oberon. I think I just skimmed them cuz I don’t recall the specifics. Maybe posted them somewhere. Anyway, I had saved Metaprogramming in Oberon from 1994 and had a bookmark on Reflection in Oberon a few years later. Maybe you’ll find them interesting.

              1. 1

                Maybe you’ll find them interesting.

                As always… ;-)

      2. 2

        its syntax is heavily dated though.

        At a first glance, uppercase keywords gave me the same impression.

        But actually they serve the same purpose of syntax highlighting without… syntax highlighting.

        Is there anything else that make it seem dated to you?

        Or, in other terms, what do you mean by “heavily dated syntax”?

        1. 3

          With “heavily dated syntax” I mean that the syntax is reminiscent of the Pascal/ADA/Eiffel era, nothing wrong with that but most developers will probably think it’s ugly, archaic and verbose. Adopting a syntax looking more like Nim will be more forgiving to developers who are new to Oberon IMO.

          1. 3

            In addition Oberon could be a lot more expressive with just adding a pipeline operator (as sugar for nested procedure calls):

            cart := emptyCart |> AddItem(42) |> MakePayment(73.95)

            1. 1

              My first impression as well, but then, Wirth consistently designs for easy-to-parse grammars, and I would argue that this is definitely a benefit, both for compiler builders and for programmers.

              also it is nice to see some cleanups of the pascal syntax, much less writing of begin, i.e. optimizing for block usage in loops and if-statements, etc.

              I am still undecided on all-caps keywords. First impression is MEH and the impression that it looks very old-school. Second look: I can get used to that. Third look: not quite sure whether it is worth it, but it definitely helps without syntax highlighting.

              1. 1

                …Wirth consistently designs for easy-to-parse grammars, and I would argue that this is definitely a benefit,…

                Just replacing symbols in the scanner with ones that are easier to type and more familiar to read by most developers doesn’t make it any less easier to parse.

                I do agree that all-caps keywords definitely help without syntax highlighting.