Modula-3 Revival

[dmuysers]

As a long-term M3 user I was pondering about a less ambitious, easy to use, platform-independent version of my favorite language reponding to the requirements of modern desktop or web-based application programming.
After having a look at Go, C# and Rust, I used chatGPT to put order into my ideas.
Here are the conclusions
M3-Revival.pdf

[norayr]

heh, hello to another oberon fan. i think m3 can be appealing to contemporary developers exactly because, unlike oberon/cp it has generics and exceptions. you mentioned several features of oberons, why not to use oberons intstead? i think language was designed by a very competent team, and i don't feel myself competent enough to propose any changes to language design. however i think that the compiler itself and build process could be improved. while i personally dislike llvm a lot for its complexity, size, and license, well that could be one of the future targets. there is QBE which is a simple project, that can be other target too. the question is - who'll do that? if you feel you have time and energy for this, i think noone will object adding new compiler backends. however, again, i think for now m3 design is "sacred" and prior to thinking of changing the language, the compiler build process could be better documented and improved and backend targets could be added. norayr

…

On Wed, 11 Jun 2025 03:08:56 -0700 dmuysers ***@***.***> wrote: As a long-term M3 user I was pondering about a less ambitious, easy to use, platform-independent version of my favorite language reponding to the requirements of modern desktop or web-based application programming. After having a look at Go, C# and Rust, I used chatGPT to put order into my ideas. Here are the conclusions [M3-Revival.pdf](https://github.com/user-attachments/files/20688727/M3-Revival.pdf) -- Reply to this email directly or view it on GitHub: #1208 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[dmuysers]

Because Oberon, which I used before M3 (Im 90 and have known N.Wirth, when he teached at Stanford), is no more portable than M3. I prefer M3's type system and the possibility of nested scopes, but, pls, no exceptions and macro templates, and platform dependencies. And no Oberon version (cf. Oberon.org) thinks about i18n, without which no application programming is possible nowadays.
Also, it is possible to add collections without generics. e.g. John Gough's Component Pascal extensible arrays, which can be used as lists or stacks, and D. Dagaev's (unfortunately undocumented) std collection library. And Component Pascal -as most Oberons- has no provision for parallelism, such as (green) threads or "goroutines".
One might notice that programming languages, as time goes by, tend to become more and more complicated,
Which is the case of M3,. And Go, after the addition of type parameters, has become incredibly messy.

[VictorMiasnikov]

the compiler itself and build process could be improved

Which version of cm3 are You using? Are You sure what it is up-to-date? And please see about LLVM13 and (or) LLVM18 near.

[VictorMiasnikov]

lvm ( . . .) could be one of the future targets.

I hope that is allready done:

https://github.com/VictorMiasnikov/cm3/releases/tag/d5.11.9-ZZYYXX-20230414_07-32

cm3-all.M3_BACKEND_MODE.eq.StAloneLlvmObj.cm3-all-AMD64_LINUX-d5.11.9-AMD64_LINUX.Debian_11.3.0-1_and_.GCC_11.3.0.-2023-04-28_13-43__FIXed__by__VVM__2023-06-07_17-07__AMD64_LINUX__Target__cm3-01eb1d0.tar.xz

"Ready to use" source code:

cm3-all.M3_BACKEND_MODE.eq.StAloneLlvmObj.cm3-all-AMD64_LINUX ( . . .) Source.Code.tar.xz

P.S. I have LLVM13 and (or) LLVM18 for AMD64_NT too

P.P.S.
"Visual part":
= =

= =

[VictorMiasnikov]

Сomponent Pascal -as most Oberons- has no provision for parallelism, such as (green) threads or "goroutines".

Please see, Active Oberon

[mikanystrom-intel]

I read your PDF, and I am not sure what it would actually simplify---what problem are you trying to solve here?

I personally think Modula-3's greatest problem is the unclear license terms, which has made it difficult to distribute. And possibly some animosity from the GNU people.

Second problem is the issues with the compiler that norayr pointed out. RISC-V support would be nice, as would having the C back-end work and be binary compatible with the gcc back-end. As I have documented elsewhere, I can only use the gcc back-end for various reasons and that makes setting up the system very tricky and error-prone.

As for the changes you propose:

Personally I think I could live without exceptions but I'm not sure I could live without generics. Why is binary size so important in this day and age when every computer has gigabytes of memory? As long as the "active set" of the program is small enough to fit in L1 cache, why do we care about large binaries (to a point...)?

I know that removing exceptions would simplify the implementation (we could remove the hidden exception-catching stack frames), but what would be accomplished by removing generics from the language?

I mostly like the language just fine as it is. How do you mean that the language has become more and more complicated when it has barely changed since the 1990s? (LONGINT and WIDECHAR are all I know about, and not entirely happy about those!) I think there remains a need for a safe system programming language like it.

Oh and we're very bad at marketing. But partly that's also an issue with the open-source community. I don't think a lot of strong OSS people are that interested in maintaining some old software. Everyone has to make a lot of changes or there's no "buzz" about it. That's not something you want for a programming language, I think. I like it just fine when my code that's over 25 years old "just works" with no changes and I don't have to tinker with new features all the time.

[VictorMiasnikov]

(

} I ( Mika Nyström) can only use the gcc back-end for various reasons and that makes setting up the system very tricky and error-prone.

I use gcc back-end too. But using "m3cc backend" is not tricky
)

About RISC-V :

"RISC-V support is implemented in the C back-end but it is currently missing from the GCC back-end. Adding RISC-V support to the GCC back-end would be advantageous, particularly if it ensures binary compatibility with the mainline GCC C language runtime."

Can this solve a problem?

P.S. IMHO, As additional, RISC-V is one of targets of LLVM13 / LLVM18

[mikanystrom-intel]

Well, ok, I have never used the LLVM back-end. What I mean is "tricky" is bootstrapping the compiler from the CM3 git repo to get to a working gcc compiler. You have to compile the C version first, then you have to go into the source code (at least the scripts), make some pretty non-obvious changes (to someone doing this for the first time anyhow), then rebuild everything with the C-generating version. This procedure does seem to work but it's not really obvious for a newcomer, or that it is even possible to do that. I would love for it to be easier so that I could distribute software written in Modula-3 and have the recipient be able to install the compiler and build rather than needing a "Modula-3 expert" to do it. (Not many of those in the world!)

[RodneyBates]

On 6/11/25 05:08, dmuysers wrote: As a long-term M3 user I was pondering about a less ambitious, easy to use, platform-independent version of my favorite language reponding to the requirements of modern desktop or web-based application programming. After having a look at Go, C# and Rust, I used chatGPT to put order into my ideas. Here are the conclusions M3-Revival.pdf <https://github.com/user-attachments/files/20688727/M3-Revival.pdf>

Currently, CM3 handles the entire range of Unicode code points in WIDECHAR, ARRAY OF WIDECHAR and TEXT. Characters can be moved between any combination of these as well as CHAR and ARRAY OF CHAR, either by procedures in Text.i3 or direct assignment, with bounds checks on assigning to CHAR.  ARRAY OF CHAR, ARRAY OF WIDECHAR, and TEXT can all be randomly subscripted by a character number directly, with no concern for variable-length encodings, unlike UTF-8.  TEXT.Ts can be pieced together with a mix of ISO-Latin1 and full Unicode characters, and dissected, with no concern for the internal representation.  There are escape sequences available in all forms of character-containing literals for specifying characters that are nonprinting or not in the source code character set ISO-Latin-1. (Or even ones that are, if you want to specify them that way.)  TEXT.Ts are immutable, as they always have been. As for input and output, procedures in UniCodec.i3 in libunicode, will read (using a Rd.T) or write (using a Wr.T) while converting between WIDECHAR and any of 9 different character encodings, including UTF-8, all the other Unicode encodings, and some older ones.  The choice of encoding is dynamic. For whole streams instead of single characters, UniRd.i3 and UniWr.i3 duplicate the functions of Rd.i3 and Wr.i3, on the entire Unicode range, converting between any of the 5 in-memory forms above and the the 9 encodings.  They also handle any of the 5 Unicode-defined end-of-line sequences.  If you need to convert memory-to-memory, existing TextRd and TextWr can be used in conjunction to do it.

…

— Reply to this email directly, view it on GitHub <#1208>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSVZNDU4NGEEKTGFTYFEKD3C753PAVCNFSM6AAAAAB7CCUBRWVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZYGQ2DAOJTG4>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[VictorMiasnikov]

libunicode

In this case size of WIDECHAR equal 4 ? ( I time to time prepare releases with "21 bit in 4 bytes" UNICODE . Can sence prepare modern binaries? )

[gundam00]

Personally, GENERICS must stay in M3.
I've ported ~ 20 years of my C/C++ (string, linear algebra, VRML, {OpenGL/3D}, etc.} libs/exes to M3 and M3's generics have an important role.

M3's generics are fun to use in contrast to C++'s potential template-nightmare.
I found M3's generic's having relatively little "cognitive load" and very versatile.
I suppose, after years of C++ "template alchemy" through SFINAE ("Substitution Failure Is Not An Error"), etc. rules, M3's generic are a bonus due to being relatively simple.

That the formal-import(s) of a GENERIC interface/implementation are at the interface (not type) level are what makes M3's generics very versatile (i.e. powerful) while relatively simple in contrast to C++'s potentially messy template system.

While the instantiation of a generic interface/implementation with it's formal imports in M3 may appear like a macro, coding a generic interface/implementation is fine (resembling in large part to non-generic M3 coding).

They "just work" .... through ease of coding.
Whilst the C++ community has , or relies on, books specifically about template programming, the M3 community has no need of such books.

With the versatility of M3's generics and the resultant sizes of my libraries/executables, "binary size" has not been something I think about.

M3 is simple, in contrast to C++, but still powerful.
No need to water it down.

OTOH, consider two version of M3:

• M3-STD --> "standard Modula-3"; i.e. what we have now
• M3-LITE --> "lightweight Modula-3"; i.e. M3-STD without {exceptions, generics}.

====================================================
Re: My {C++ --> M3} odyssey .....

"FROM C++ TO MODULA-3 ... (28 March 2024) #1177"
#1177

"FROM C++ TO MODULA-3 ... (12 Jan 2025) #1199"
#1199

[thielema]

On Wed, 11 Jun 2025, gundam00 wrote: OTOH, consider two version of M3: * M3-STD --> "standard Modula-3"; i.e. what we have now * M3-LITE --> "lightweight Modula-3"; i.e. M3-STD without {exceptions, generics}.

We already had ezm3.