Luon programming language

I don't use TurboLua, but I think it's feasible to build a Luon adapter module if need be. The necessary 'extern' keyword is already part of the spec.

What do you mean by "natively"? Ahead of time compiled, or just working? If the latter, the present VM is already available on the mentioned systems. In my version, Gingko, I additionally removed a lot of outdated code to increase platform independence.

Actually, I only use original Oberon when I'm migrating the old Oberon systems. My interest lies in finding out how I would have to modify original Oberon to be as productive as I am used to with e.g. C++, but still adhering to the goal of simplicity. My version, which I call Oberon+ (and to which Luon is quite similar, whereas Luon is even simpler), goes in this direction.

Actually an "edge over more currently popular languages" from my humble point of view is the goal and maintenance of simplicity. The term is subjective, but if you look at many of today's completely overloaded languages, it is intuitive to understand.

Could I ask why you find yourself working on older machines? Work? A fan of retro computing? Something else?

Even VIM has support for LSP in extensions, I'm sure there's some lightweight LSP supporting editors out there.

Records, arrays and hashmaps are structured types; in contrast to original Oberon, Luon has no pointer type, but reference semantics instead.

Welcome. Actually we learned Modula-2 when I was at ETH in the eighties, and I had even a job at DEC Switzerland for some time where I had to develop course ware for the VAX Modula-2 compiler, but it was from DEC as far as I remember (probably this one: https://github.com/GunterMueller/DEC-Modula-2). Luon is actually a subset of my Oberon+ language; maybe you want to have a look at it: https://oberon-lang.github.io/.

Off by one issues are also an argument given in favour of no indexing.

    groups=new Array(3).fill([])
    items.reduce(function(a,x,y){y=a.shift();y.push(x);a.push(y);return a},groups)

    groups:3 0N#items

    groups = table.reshape(items,{3,nil})   -- numlu?
    groups = items.reshape([3,null])        // numjs?

On the other hand, Erlang is also 1-based, and there's no numerl I know of, so I might write:

    f(N,Items) -> f_(erlang:make_tuple(N,[]),Items,0,N).
    f_(Groups,[],_,_N) -> Groups;
    f_(G,Items,0,N) -> f_(G,Items,N,N);
    f_(G,[X|XS],I,N) -> f_(setelement(I,G,X),XS,I-1,N).

    n = 0
    for i = 1,#items do
      if n < 1 then n = #groups end
      table.insert(groups[n],items[i])
      n = n - 1
    end

The cool thing about one-based indexes is that 0 meaningfully represents the position before the first element or not-an-element. If you use zero-based indexes, you're forced to either use -1 which precludes its use for referring to the end of the list, or null which isn't great for complicated reasons. There are other mathematical reasons for preferring 1-based indexes, but I don't think they're as cool as that.

Your second example subtracts and adds 1 nearly arbitrarily, which wouldn't be needed if the convention of the 0-index wasn't so widespread.

why not just iterate in steps of three over items for each next group? seems a bit contrived.

> Why shouldn’t an array at the smallest possible index correspond to the beginning of the array?

Because then there is no good way to refer to the index before that point: You are stuck using -1 (which means you can't use it to refer to the end of the array), or null (which isn't great either).

> every programming language I know of that supports the concept of unsigned integer

Surely you know Python which uses a signed integer as an index into their arrays: list[-1] is the last element of a list. If they only used one-based indexing then list[1] would be the first and that would be nicely symmetrical. It would also mean that list[i-1] would NEVER refer to a value after ‹i› eliminating a whole class of bugs.

> It’s also very natural to think of arr[i] as “i steps past the beginning of arr.”

I think it's more natural to think of arr[i] as “the ‹i›th element of arr” because it doesn't require explaining what a step is or what the beginning is.

The exact value of ‹i› matters very little until you try to manipulate it: Starting array indexes at one and using signed indexes instead of unsigned means less manipulation overall.

> find the convention used in many countries of numbering building floors starting with zero to be more logical

In Europe, we typically mark the ground-floor as floor-zero, but there are often floors below it just as there are often floors above it, so the floors might be numbered "from" -2 for example in a building with two below-ground floors. None of this has anything to do with arrays, it's just using things like "LG" or "B" for "lower ground" or "basement" don't translate very well to the many different languages used in Europe.

The software in the elevator absolutely doesn't "start" its array of sense-switches in the middle (at zero).

In India too, the floor at the ground level is called the ground floor (probably that is where the name came from), the one above it is called the first floor, and so on. The convention is probably from British colonial times.

Also LED floor numbers in lifts (elevators) in India start from 0 for the ground floor, as do the buttons that you press to go to specific floors.

Also, Ground Zero.

https://en.m.wikipedia.org/wiki/World_Trade_Center_site

https://en.m.wikipedia.org/wiki/Hypocenter#

> I also, despite being American, find the convention used in many countries of numbering building floors starting with zero to be more logical. I’m on the third floor, how many stories up did I travel to get here? Three.

Alternatively the ground floor is the first floor because it’s the first floor you arrived at when you entered the building.

The same point of view applies to 1-based indexing.

That said I prefer 0-based in programming and 1-based in buildings.

> find the convention used in many countries of numbering building floors starting with zero to be more logical.

Ukrainian here. Multi-floor buildings always have at least one stair section to first floor due to need of thermal basement isolation. (I guess this is not pertaining to Western Europe due to more clement winters.) And, yep, it is called "first" floor. Using zero number is rare but possible (in this case it is called "tsokolny" floor) if a real "basement floor" is present, but in this case still 1-based numbering is preferred.

I'd argue that 1-based indexing is the "natural interpretation". Mathematics is inherently 1-based, and it isn't surprising that languages designed to do mathematics like R, Matlab, Mathematica, Julia all do 1-based arrays because that makes modeling paper mathematics in programs easier.

IIRC some BASIC(s) I've used in the past had a statement called:

OPTION BASE 1

or something like that, to change the starting index to 1.

> There are 360 degrees in a circle, and the first entry is 0 degrees.

To be pedantic, "first" is associated with 1. And a circle does not have a "first" entry, whatever you mean by entry. I think what you're trying to say is that a circle is a continuous arc going from 0 to 360 degrees, but you should recognize that the "starting point" is arbitrary, any point will do, so there isn't really a "first", and that this is not the same as counting because counting is done with natural numbers, which are non-continuous. The problem of 0 VS 1 makes sense only in counting exactly because it's subjective whether you prefer to count from 0 or from 1. Because zero is the absence of anything, I find it hard to start counting from 0 (when you do, your "first" item is actually your zeroth item, and the next item would be the "first"??!), to be honest, despite being completely familiar with doing so since I've used 0-index programming languages my whole life.

Also, how many years old are you when you're born? Zero. (at least in mainstream Western culture).

I've been in the US for over a decade and it still occasionally makes me double-take when a room numbered 1xx is on the ground floor

I find that argument to be written in a terse "mathy" style that makes it a bit hard to follow. So let me try to restate it in more concrete "programmy" terms.

To iterate over an array with "len" elements, it’s most elegant if “len” appears as a loop bound, rather than "len+1" or "len-1". Thus, in 0-based languages we use half-open ranges, whereas in 1-based languages we use closed ranges:

  // real C
  for (int i = 0; i < len; ++i)
      process(array[i]);


  // C-like language with 1-based indexing
  for (int i = 1; i <= len; ++i)
      process(array[i]);

Yeah, I disagree with Dijkstra on this. And many other things.

Quite high abstraction for its simplicity, quick to learn, strongly typed, garbage collected before it was cool (same as Module 3) and yet a system programming language (Oberon OS).

You could argue that Wirth overdid it a bit with the simplicity vs. Comfort features but that's probably also dependent on your preferences and the problem you want to solve.

There are a few languages where you regret that they did not win in favour of C++ and Oberon is one of them (and Modula 3). Not that C++ does not have its strength , but for many problems Oberon would probably have been the simpler fit.