Live data from Hacker News

The Oberon+ Programming Language

oberon-lang.github.io

101–110 of 116 posts

Re: The Oberon+ Programming Language

#101
post #7
post #3

I don’t like how verbose Pascal-like languages are. I don’t want to have to type tons of keywords to get anything done. Curly brackets are a big improvement over pairs of “begin” and “end” all over. Makes it hard to see the forest for the trees when skimming some code to figure out what it does. That on its own makes something like this a complete nonstarter for me, leaving aside issues like support, quality of imple…

I think it's less about typing them and more about reading them. Curly braces reduce the number of keywords in the language (unless the alternative is indentation sensitivity like in Python or Haskell). This means that if I see a word, it is easier to infer if it is a variable name or if it does something structural. How about a treesitter-based editor extension that converts between begin/end and {/}, as if they wer…

> How about a treesitter-based editor extension that converts between begin/end and {/}, as if they were ligatures? Actually this might not even need treesitter.

Neovim has the conceal feature, which can convert Treesitter nodes into a single symbol, but not the other way around unfortunately.

Re: The Oberon+ Programming Language

#102
post #96

looks like an absolutely uninteresting boomer language, by the fact that it just shows standard imperative stuff followed by "wow it supports unicode, we are up to date"! (which is a misfeature, btw, i like being able to audit my code before running it (not that thats possible in the current mess of misconceived computers but yeah still it would be good to start doing things in the right direction). its interesting t…

SyntaxError: expected ')', found end of comment

How does Unicode support make it harder to audit code?

Re: The Oberon+ Programming Language

#103

Earlier quoted context omitted.

C (and C++) considers the declaration to be separate from the definition, though you can combine them. The declaration is the name + type, definition provides a value. The example code is meant to illustrate separate declaration and definition with some code (the call to `f`) between the two. If you try to use `x` before it is defined (the assignment) your compiler should give you a warning, at least. If it doesn't,…

For block-scope declarations, it's not the definition but the initialization that you're thinking of. At least in C, every block-scope variable declaration is a definition: > A definition of an identifier is a declaration for that identifier that: > — for an object, causes storage to be reserved for that object; [...] But initialization (in C) does not occur for block-scope objects without the optional initializer.

Okay, that's somewhat confusing. So a declaration is when the identifier enters the scope, and a definition is for a variable specifically. So a declaration that's not a definition could be a forward declaration for a function, or a typedef.

Re: The Oberon+ Programming Language

#104

The justification for putting generic types on modules is interesting. It seems they tried a lot of other variations but couldn't find one that was simple: https://oberon-lang.github.io/2021/07/17/considering-generic...

A few years ago i was also thinking of how Oberon-07 could be extended to support more generic types - mainly so containers, etc, can be more type safe - and pretty much came to the same conclusion that putting types on the modules themselves is by far the simplest approach. Though my approach was a bit different (judging from the code examples) in that parametric modules were more like templates that were specialize…

Besides that, Active Oberon already supports generics in a way similar to Modula-3.

Re: The Oberon+ Programming Language

#105
post #104

Earlier quoted context omitted.

A few years ago i was also thinking of how Oberon-07 could be extended to support more generic types - mainly so containers, etc, can be more type safe - and pretty much came to the same conclusion that putting types on the modules themselves is by far the simplest approach. Though my approach was a bit different (judging from the code examples) in that parametric modules were more like templates that were specialize…

Besides that, Active Oberon already supports generics in a way similar to Modula-3.

The original Active Oberon (Reali, 2004) didn't have generics; you probably mean the ETH Oberon (2019) Language Report draft by Felix Friedrich; I don't think it's implemented somewhere.

Re: The Oberon+ Programming Language

#107
post #7
post #3

I don’t like how verbose Pascal-like languages are. I don’t want to have to type tons of keywords to get anything done. Curly brackets are a big improvement over pairs of “begin” and “end” all over. Makes it hard to see the forest for the trees when skimming some code to figure out what it does. That on its own makes something like this a complete nonstarter for me, leaving aside issues like support, quality of imple…

I think it's less about typing them and more about reading them. Curly braces reduce the number of keywords in the language (unless the alternative is indentation sensitivity like in Python or Haskell). This means that if I see a word, it is easier to infer if it is a variable name or if it does something structural. How about a treesitter-based editor extension that converts between begin/end and {/}, as if they wer…

I'd rather have systematic "language skinning", where different flavors (begin and end versus { and }) are isomorphisms of each other so one's tooling can fluidly translate between both forms.

Rochus is almost kind of doing this with Oberon+ versus Wirthian Oberon already, but it would be nice to go further.

Re: The Oberon+ Programming Language

#108
post #89

Earlier quoted context omitted.

> I like having a few different loops to keep code more readable. When they have similar semantics, and are not arbitrarily designed. In Oberon: - while has an elseif statement. Repeat is a do/while, doesn't have an elseif statement - loop is allowed an exit. No other loops are allowed to terminate early. And that is literally the only reason loop exists etc.

The last point is very likely by design: Only when you see a LOOP do you have to worry about early exits. For the other, more common constructs, you instantly know there won’t be an exit somewhere in the middle, and you can reason about its termination behavior solely based on the loop conditional.

It's not by design, not really.

Early Pascal/Modula/Oberons were extremely anal about loops (of any kind) never having any early exits, ever.

Then they ran into the real world.

So each consecutive version of Oberon either added early returns or removed early returns. Sometimes like clockwork. And also added/removed other types of loops in pursuit of some unspecified ideal of simplicity.

You can see part of that history in the overview of differences: https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w...

So it's a self-imposed constraint that makes very little sense.

Re: The Oberon+ Programming Language

#109

Earlier quoted context omitted.

For block-scope declarations, it's not the definition but the initialization that you're thinking of. At least in C, every block-scope variable declaration is a definition: > A definition of an identifier is a declaration for that identifier that: > — for an object, causes storage to be reserved for that object; [...] But initialization (in C) does not occur for block-scope objects without the optional initializer.

Okay, that's somewhat confusing. So a declaration is when the identifier enters the scope, and a definition is for a variable specifically. So a declaration that's not a definition could be a forward declaration for a function, or a typedef.

Yes, or the declaration of an extern variable.

Re: The Oberon+ Programming Language

#110
post #105
post #104

Earlier quoted context omitted.

Besides that, Active Oberon already supports generics in a way similar to Modula-3.

The original Active Oberon (Reali, 2004) didn't have generics; you probably mean the ETH Oberon (2019) Language Report draft by Felix Friedrich; I don't think it's implemented somewhere.

Naturally I mean the latest version.

As for it being implemented, I was assuming that by now it already was, given that it is still being actively developed.

Post reply on HN