A little language extension that would save a lot of typing

[dmuysers]

(borrowed from Oberon)
ArrayType = ARRAY [Index {"," Index}] OF Type.
Index = Type | ConstExpr. // 'n' same as '[0..n-1]'

[nsgnkhibdk2cls0f]

(borrowed from Oberon) ArrayType = ARRAY [Index {"," Index}] OF Type. Index = Type | ConstExpr. // 'n' same as '[0..n-1]'

First, which Oberon? Oberon-2 or Oberon-07?

Second, please give example code, not language grammar. I don't understand language grammar (is this EBNF?).

[mikanystrom-intel]

I don't care if they are the same thing or not. On my dictionary, writing a data structure and methods but without an already known type specified that could be later re-used for other types just by plugging the type into it is called generics.

Modula-3 generics don't operate on types, neither as input nor as output. They take modules as input (parameters) and produce modules as output.

[1997tn]

Template class of C++, but closer to macro. The module word sounds fancy, but it's really just equivalent to class in other class based languages. On C++ and Java, each class usually lives on it own source file (just like M3's module, C++ has header (.h) and implementation (.cpp) separation, just like M3's .i3 and .m3), even though they support nested classes. Module maps well to class.

[mikanystrom-intel]

Template class of C++, but closer to macro. The module word sounds fancy, but it's really just equivalent to class in other class based languages. On C++ and Java, each class usually lives on it own source file (just like M3's module, C++ has header (.h) and implementation (.cpp) separation, just like M3's .i3 and .m3), even though they support nested classes. Module maps well to class.

Guys, you're confusing the language definitions of mechanisms with common usage models. They are not the same. And this kind of wishy-washy vagueness tends to lead programming discussions completely astray.

I don't know C++ well enough to comment, but take C. You can search high and low for "header" and "implementation" in the C language definition, and you won't find it. It's not actually part of the language at all. Instead, programmers have developed conventions about how to use mechanisms, in C in particular #include, to do things that are interesting from a software-engineering point of view. In the case of C headers, what they are trying to do is to simulate Modula modules, which is a concept that otherwise does not really exist in C itself. (One of the best books on how to write C "modules" is by the way based on Modula-3's libraries---Hanson's book.)

In the same way, Modula-3 modules are not classes, nor are Modula-3 generics classes, or types, or parameterized types. Modula-3 modules are collections of declarations and definitions, and Modula-3 generics are actually just very cleverly written IMPORT statements (you can call them macros but in that case they are very very restricted macros, since the only thing they let you change is the "x" in IMPORT x AS y), which semantically link together these modules.

What makes it possible to use Modula-3 generics to do type templates is conventions among Modula-3 programmers. In particular, the convention to define approximately one important type per interface module and call that type "T". Nothing about the Modula-3 language definition requires anybody to code like this.

As a programmer, you are not necessarily bound by these conventions. I remember a time when C++ programmers put most of their executable code in .h files, for example. And you can use Modula-3 generics to do things very different from defining new object types (classes).

The main difference between modules and classes by the way is that modules, as well as their constituent components, aren't in any kind of semantically enforced type-subtype relationship to each other. As an example, this allows you to do things with M3 generics that "look and smell" like multiple inheritance even though the M3 type system doesn't allow multiple inheritance between object types.

The most common "other thing" I have seen M3 generics used for is to define not type hierarchies but linked type hierarchies (so a generic interface module could for example define two or more derived types, which needn't be in any particular typing relationship between themselves, of two or more base types).

And yes while the M3 generic implementation is very simple, I don't see why this is a drawback. Figuring out "how to name objects" is one of the most difficult problems in formal logic (of which programming languages are a subset) and having a mechanism that does that reasonably by simple means ought to be a point of pride, not something that needs to be excused.

Another comment here is that when you learn about a new programming mechanism, ask not what you can do with it---but ask what you CANNOT do with it (how does the design of this mechanism prevent me from shooting myself in the foot?) It is very hard to shoot yourself in the foot with Modula-3's generics. (As opposed to, say, a general unhygienic macro mechanism such as that provided by cpp.)

[nsgnkhibdk2cls0f]

M3's generics is very similar to Vector Pascal's: https://sourceforge.net/projects/vectorpascalcom/

Download it and read manual.pdf, you will see, very similar.

[mikanystrom-intel]

M3's generics is very similar to Vector Pascal's: https://sourceforge.net/projects/vectorpascalcom/

Download it and read manual.pdf, you will see, very similar.

I am not sure why anyone on this list should care about how Vector Pascal does things.

But I am open-minded and did as you said. And you totally missed my point (or ignored it).

Vector Pascal uses types as parameters to what it calls "parametric units". I see nothing wrong with this.

But my point was that Modula-3 DOES NOT USE TYPES AS PARAMETERS TO GENERICS!!

MODULA-3 USES INTERFACE MODULES AS PARAMETERS TO GENERICS!

Two things are not similar just because it looks similar or has a similar name! A photo of an elephant is not an elephant!

[dmuysers]

| @dmuysers maybe you will like Oberon+: https://github.com/rochus-keller/Oberon
No.

1. It's GPLed, rather than MIT ot BSD
2. It did not implement the latest features of the official Active Oberon 2019

[nsgnkhibdk2cls0f]

1. What's wrong with being GPL-ed? CM3 is also GPL-ed, why are you here?
2. Rochus Keller has his own design. The language is named Oberon+, not Oberon. Why does he need to implement Active Oberon 2019? Active Oberon 2019 is another language. Most if not all Oberon compilers on Github only implement original Oberon. I don't see Active Oberon 2019 has anything superior than what Oberon+ already has.

[nsgnkhibdk2cls0f]

IMO Oberon is just a brand now. They do anything to sell it to the public, an Oberon-2 even called itself Component Pascal, of course there is no Pascal in it, Pascal is only used as a brand. Same as Oberon now, just a brand, a marketing buzzword. Original Oberon's latest version is Oberon-07. Active Oberon, Zonnon,... are other derived languages that used the brand Oberon.

[nsgnkhibdk2cls0f]

Active Oberon language report: https://gitlab.inf.ethz.ch/felixf/oberon/-/blob/main/docu/OberonLanguageReport.pdf

I don't see any breakthroughs. The life and evolution of Oberon is just you trimmed the language too much so you have to re-add it, then you feel it's bloated so you started to trim it down even further only to realize your language is now so useless and you have to re-add something you removed back and this keeps repeating. Because Original Oberon is too useless as it was trimmed down too much, derivatives like Active Oberon, Zonnon (derived from Active Oberon), Component Pascal (derived from Oberon-2) have to add some of the features back and they called it as improvements!

[1997tn]

@dmuysers If you liked Oberon, there are a lot of Oberons on oberon.org for you to choose from :)