Is it possible to introduce your own extensions?

[ghost]

CM3 is the only active M3 compiler still in development so you don't have to care about compatibility with anything. Don't blindly follow the language definition, like it's the language definition said the sun rise in west then you have to say so too. Don't let the language definition dictate what you could do. Remember, you are the upstream now. You don't have to follow anyone else. That language definition has long not updated and very outdated. The mindset here from the issues I have read is kinda it's wrong but it's simply this way as the language definition (the "manual") said so it's the "expected" behavior. You refused to fix it for the better only because to stay loyal to the outdated manual. It's so wrong! You are the upsteam now. Remember it, you are the upstream. If you need you could change that language definition anytime you want. It could be implemented on top of the old manual by compiler directives or compiler options to overwrite the expected behavior. Even if you managed to call it Modula-4 then it's also OK. You are free! You are absolutely free! Why can't you simply do whatever you want to make the language better to constrain yourself to what?

Do you want the language to move ahead or become a dead language already? Think about it.

[mikanystrom]

Are you talking about something specific?

For me, the stability of the language is one of its biggest "features". It's amazing actually, to know that I have lots of modules I wrote 20+ years ago that still "just work" without having been edited since.

Yes there are things that could have been done differently, but ...

1. you DO have to at least rewrite the documentation, that's where you'd start, I think
2. you'll probably break a lot of existing code. Who will clean up that mess?

Some years ago, LONGINT was added, and while it was a very minor addition to the language, it really caused quite a lot of problems.

But I'm also not sure what you are talking about is "outdated". Is Hamlet outdated? Is there a specific issue you have in mind?

[ghost]

Did you notice a lot of tickets were simply disappeared together with their authors? I bookmarked a bunch of them to be used as examples, now all of the links become 404 not found. Github doing something fishy under the scene? The users created these tickets simply disappeared from Github like have never existed. I have eyeing on M3 long before actually started this thread. It's disappointing.

[ghost]

For me, the stability of the language is one of its biggest "features". It's amazing actually, to know that I have lots of modules I wrote 20+ years ago that still "just work" without having been edited since.

This is why I proposed compiler directives and compiler options to override the existing behaviors. See how Free Pascal did it to get inspired. And if it's considered as inconvenient to do so, then make it Modula-4 and done. M3 code is still compile as is as always.

[mikanystrom]

Some people deleted their github accounts in some sort of frustration. I guess their posts are then deleted?

I am still not sure what you are talking about. If you add directives and options to do "other things", that will soon become the default. Do you have a specific example of something you think needs to change?

The biggest problem for wider adoption of M3 in my opinion has nothing to do with the language itself, or even its tools, but with the somewhat murky licensing situation. And the old feud with the FSF, which I guess isn't entirely unconnected. Linux guys playing politics and all that...

By the way, changing the language forces a lot of existing code to change even if it's "optional". There are a number of tools in the M3 tree that work on M3 files (in particular INTERFACEs) as their input. All that would have to track whatever it is you change, and it's not pretty to make it compiler directives and compiler options. How would the M3 processing programs know what your set of directives and options are if they aren't present directly in the source files? This kind of thinking is what was behind some of the very deliberate decisions, way back, to make the language single-source and not have macros, preprocessors, etc. I think that thinking is still very relevant, and in a sense, it's ahead of a lot of other languages even today.

[ghost]

As these tickets are gone I'm unable to show you anything. Sorry.

The biggest problem for wider adoption of M3 in my opinion has nothing to do with the language itself, or even its tools, but with the somewhat murky licensing situation. And the old feud with the FSF, which I guess isn't entirely unconnected. Linux guys playing politics and all that...

Windows alone is already a large enough audiences. But it seems you don't care about these users. For example, when searching for Modula 2 what Google suggests you will be Stony Brook M2 (now called ADW: https://www.modula2.org/adwm2/), not GNU M2 or any other variants (XDS M2,...). Why? Because Stony Brook is the most popular M2. Stony Brook is closed source and Windows only. Too much of a limitation. Why it's the most popular? Because it introduced it own extensions and have a complete Windows API support to make people coding in M2 on Windows with ease. Did you do anything like that?

[ghost]

murky licensing situation.

Did you try to split the distribution into cm3-core and cm3-extras? This scheme is used by many projects. cm3-extras will be for the problematic licensing parts.

[RodneyBates]

Well I have to disagree adamantly about dumping a language definition and letting the behavior of a compiler be the defacto definition. You may not be old enough to have experienced this, but I started coding in the era when FORTRAN and COBOL were the only languages, and when the reality was it was largely done that way.

Trying to figure out by experiment what various code actually does is an utter nightmare for the hapless programmer.  Aside from an experiment's taking a lot more time than referring to a document, it is only anecdotal, and inferring what the general rules are from multiple experiments is a minefield, guaranteed to lead to never-ending blindsiding.

That said, in the case of Modula-3, there are definitely places where the definition could be updated, possibly some that are actually bringing it into consistency with the compiler.  I have a number of notes of such changes on my to-do list.  All or very nearly all are just clarifications.  At least one is documenting currently undefined behavior, that has been discussed in this forum with, I believe, a consensus reached.  None of it breaks backward compatibility.

As for the documented behavior itself being "outdated",  you miss the whole concept of Modula-3's design. While the Oberons, etc. are indeed smaller by perhaps 3x, Modula-3 is entirely unmatched for economy of concept.  That means you get a high ratio of valuable features to language complexity.  Languages like C++, Java, and Ada have language definitions 6x to 10x larger, while lacking some really useful features, yet also cluttered by some features that have zero or negative value to the coding and maintenance processes.

I think you will find the Modula-3 community is quite protective of this economy of concept, and also of just absolute language size. Do you have specific proposals for additions or changes?  I think they would have to be small, have minimal interactions with existing stuff, and of course, be backwards compatible.  I have a few of those myself, but I'm not hugely invested in them.

Or, as you suggest, you can start your own Modula-4.  But you might not be able to garner a lot of help from the Modula-3 community.

(Some years back, there were a couple of posts enthusiastically and impatiently announcing a Modula-4 project, but AFIK, that was forgotten very quickly.)

On 12/8/22 20:57, tn1997tn wrote:

CM3 is the only active M3 compiler still in development so you don't have to care about compatibility with anything. Don't blindly follow the language definition, like it's the language definition said the sun rise in west then you have to say so too. Don't let the language definition dictate what you could do. Remember, you are the upstream now. You don't have to follow anyone else. That language definition has long not updated and very outdated. The mindset here from the issues I have read is kinda it's wrong but it's simply this way as the language definition (the "manual") said so it's the "expected" behavior. You refused to fix it for the better only because to stay loyal to the outdated manual. It's so wrong! You are the upsteam now. Remember it, you are the upstream. If you need you could change that language definition anytime you want. It could be implemented on top of the old manual by compiler directives or compiler options to overwrite the expected behavior. Even if you managed to call it Modula-4 then it's also OK. You are free! You are absolutely free! Why can't you simply do whatever you want to make the language better to constrain yourself to what?

Do you want the language to move ahead or become a dead language already? Think about it.

— Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/1120, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSVZNHBVVOC5VEDS24FRQ3WMKN2DANCNFSM6AAAAAASY25A4M. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[RodneyBates]

On 12/9/22 01:53, Mika Nyström wrote:

Are you talking about something specific?

For me, the stability of the language is one of its biggest "features". It's amazing actually, to know that I have lots of modules I wrote 20+ years ago that still "just work" without having been edited since.

Yes there are things that could have been done differently, but ...

1. you DO have to at least rewrite the documentation, that's where you'd start, I think
2. you'll probably break a lot of existing code. Who will clean up that mess?

Some years ago, LONGINT was added, and while it was a very minor addition to the language, it really caused quite a lot of problems.

If "problems" here means something more that just controversy, from today's perspective, what problems with LONGINT can anybody cite.

But I'm also not sure what you are talking about is "outdated". Is Hamlet outdated? Is there a specific issue you have in mind?

— Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/1120#issuecomment-1343968373, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSVZNCHLODSTGORG5WDO4TWMLQONANCNFSM6AAAAAASY25A4M. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[mikanystrom]

On 12/9/22 01:53, Mika Nyström wrote: Are you talking about something specific? For me, the stability of the language is one of its biggest "features". It's amazing actually, to know that I have lots of modules I wrote 20+ years ago that still "just work" without having been edited since. Yes there are things that could have been done differently, but ... 1. you DO have to at least rewrite the documentation, that's where you'd start, I think 2. you'll probably break a lot of existing code. Who will clean up that mess? Some years ago, LONGINT was added, and while it was a very minor addition to the language, it really caused quite a lot of problems. If "problems" here means something more that just controversy, from today's perspective, what problems with LONGINT can

Only that it broke a ton of existing code. As I wrote above, there is plenty of Modula-3 code (both inside and outside of the official repository) that depends on being able to process Modula-3 interfaces as data. Changing the language spec means changing all that code. LONGINT in particular is a bit nasty because it introduces new types that can't be represented by INTEGER, which used to be the base integer type that all other integral types are derived from. And this was for temporary/limited benefit: LONGINT is not particularly useful on a 64-bit machine.

[ghost]

Well I have to disagree adamantly about dumping a language definition and letting the behavior of a compiler be the defacto definition.

I didn't said anything like that. It's the reverse: updating the language definition (not dumping it) according to the compiler, as this is currently the only active M3 compiler and thus upstream. It don't have any compatibility problems (with other M3 compilers) to care about.

[ghost]

On 12/9/22 01:53, Mika Nyström wrote: Are you talking about something specific? For me, the stability of the language is one of its biggest "features". It's amazing actually, to know that I have lots of modules I wrote 20+ years ago that still "just work" without having been edited since. Yes there are things that could have been done differently, but ... 1. you DO have to at least rewrite the documentation, that's where you'd start, I think 2. you'll probably break a lot of existing code. Who will clean up that mess? Some years ago, LONGINT was added, and while it was a very minor addition to the language, it really caused quite a lot of problems. If "problems" here means something more that just controversy, from today's perspective, what problems with LONGINT can

Only that it broke a ton of existing code. As I wrote above, there is plenty of Modula-3 code (both inside and outside of the official repository) that depends on being able to process Modula-3 interfaces as data. Changing the language spec means changing all that code. LONGINT in particular is a bit nasty because it introduces new types that can't be represented by INTEGER, which used to be the base integer type that all other integral types are derived from. And this was for temporary/limited benefit: LONGINT is not particularly useful on a 64-bit machine.

This can be workaround using compiler directives or compiler options. It's indeed a very simple problem. Only because you are too weirded from design. The language should be fine without any builtin build system. M3 instead have to rely on the quake build system to do the job. Take GNU M2 as example, you could invoke it just like gcc with compiler options passed directly to gm2. You can't do this with M3. cm3 is not an actual compiler but just a glue it together quake interpreter. Your compiler directives (pragmas) is both not well defined nor powerful. The very simple problem for other languages, just introduce new compiler options or compiler directives then become hard for you. But, it's not really hard! If everything has to go through the m3makefile build script then just implement it in the build script. I would say it's some how even easier this way.

[ghost]

The biggest problem for wider adoption of M3 in my opinion has nothing to do with the language itself, or even its tools, but with the somewhat murky licensing situation. And the old feud with the FSF, which I guess isn't entirely unconnected. Linux guys playing politics and all that...

Windows alone is already a large enough audiences. But it seems you don't care about these users. For example, when searching for Modula 2 what Google suggests you will be Stony Brook M2 (now called ADW: https://www.modula2.org/adwm2/), not GNU M2 or any other variants (XDS M2,...). Why? Because Stony Brook is the most popular M2. Stony Brook is closed source and Windows only. Too much of a limitation. Why it's the most popular? Because it introduced it own extensions and have a complete Windows API support to make people coding in M2 on Windows with ease. Did you do anything like that?

I have the impression that you are trying to dodge from this? You did nothing but blame others. Let's take an example. There is languages full of problems but still have an active community around them like BCX (BCX is the compiler of it own BASIC dialect). Even though the language is not anyway comparable to M3, BCX has excellent documentation (can be viewed on both the web or the offline help file), with excellent support for Windows API. So does FreeBASIC and QB64. You could say it's because they are BASIC dialects and should have the already large BASIC community. This is irrelevant. They are popular because the users could use it to do something real like their little Windows GUI programs or very simple games. None of these languages are as well designed as M3.

What would someone could do with M3? From the impression, it should be something like Go and fill the same market as Go. But it doesn't have the large builtin standard library Google provided with Go that offer almost anything the users will ever need. The standard library of it is a mess and lacking, even XML support (https://github.com/modula3/cm3/issues/1114) and most of the time is difficult and awkward to use because the users have to depend on m3makefile to process generics.

But, unlike Stony Brook M2 that put their resources in the correct niche market: Windows GUI development (just like BCX, FreeBASIC and QB64), M3 is completely don't care about this market. The result is it has no market. This is easy to understand.

[mikanystrom]

I think what you're saying doesn't quite make sense. You say the language needs changes, extensions, compiler flags and whatnot.

Then you go on to say that the library is lacking. All sorts of basic stuff missing.

Which is it? Changing the compiler isn't going to make new libraries write themselves. In fact it will make code churn that will make it harder to find the time to write libraries.

Now, there is definitely code to do both XML and JSON in Modula-3. But that's kind of beside the point.

You do have a real point here.

The point, I think, is that in order to get people interested in OSS, there has to be something to "do" and some development to "move forward". No one wants to work on a "dead language", as you put it.

There's a contradiction here. Those of us that use Modula-3 on a daily basis do NOT want the language to change. It was very well designed, and we learned to live with its limitations, because the alternative is WORSE. M3 is good enough that it does NOT need churn and updates and versioning Hell. But that also means that it's hard to interest smart OSS people in working on M3, because they want to work on the basics of the language, or at least basic libraries.

I do think that what M3 may need is a (big) corporate sponsor. DEC obviously was it, and then Compaq/HP for a while, but now it's abandoned from the corporate side. This is where the licensing situation is troublesome. I could not possibly get my employer to devote resources to a programming language with a murky licensing situation, and I suspect the same is true for pretty much any other company.

And yes, M3 fills much of the same sort of language niche as Go. It's a lot more stable though... since it's dead!

[mikanystrom]

On 12/9/22 01:53, Mika Nyström wrote: Are you talking about something specific? For me, the stability of the language is ... Only that it broke a ton of existing code. As I wrote above, there is plenty of Modula-3 code (both inside and outside of the official repository) that depends on being able to process Modula-3 interfaces as data. Changing the language spec means changing all that code. LONGINT in particular is a bit nasty because it introduces new types that can't be represented by INTEGER, which used to be the base integer type that all other integral types are derived from. And this was for temporary/limited benefit: LONGINT is not particularly useful on a 64-bit machine.

This can be workaround using compiler directives or compiler options. It's indeed a very simple problem. Only because you are too weirded from design. The language should be fine without any builtin build system. M3 instead have to rely on the quake build system to do the job. Take GNU M2 as example, you could invoke it just like gcc with compiler options passed directly to gm2. You can't do this with M3. cm3 is not an actual compiler but just a glue it together quake interpreter. Your compiler directives (pragmas) is both not well defined nor powerful. The very simple problem for other languages, just introduce new compiler options or compiler directives then become hard for you. But, it's not really hard! If everything has to go through the m3makefile build script then just implement it in the build script. I would say it's some how even easier this way.

You missed the point.

I have code that needs to be able to process Modula-3 source code.

All that code has to change whenever you modify the language. And every time you add a compiler option, all the code that understands Modula-3 source code has to change to match whatever new thing the compiler does. If you add compiler options and directives that change the semantics of the language, you're really causing a nightmare situation for language tools writers.

You keep saying that the compiler behaves differently from the language spec. In what sense does it do this? The compiler has implementation restrictions, sure, but what compiler doesn't? Why would those be relevant to the language spec? Those restrictions can come and go and change, be different for different architectures and bit sizes and endiannesses and who knows what else. Even using a single compiler. The goal should be to remove the restrictions as much as possible, not to document them as correct behavior!

And it's kind of a bit of a stretch to say there is only a single compiler for M3. Even without considering the other historical implementations (the PARC implementation, SRCM3 and PM3 that I know of), some aspects of the three different back-ends in CM3 inevitably bleed through to the implementation restrictions I wrote about above, and I strongly suspect that whatever deviations may exist between the implementation and the language specification are different depending on which back-end you use.

[ghost]

I think what you're saying doesn't quite make sense. You say the language needs changes, extensions, compiler flags and whatnot.

Then you go on to say that the library is lacking. All sorts of basic stuff missing.

Which is it? Changing the compiler isn't going to make new libraries write themselves. In fact it will make code churn that will make it harder to find the time to write libraries.

My point is: if your language is imperfect (like the many BASIC dialects I mentioned), you have to invest in documentation and libraries to gain traction. You misinterpreted the whole of my arguments!

Now, there is definitely code to do both XML and JSON in Modula-3. But that's kind of beside the point.

Your distribution is organized in a way make it the most difficult to find things. I know about JSON library not because I found it when searching the distribution hopelessly but because I saw the commits of @demoitem on this repo, only after that I could navigate where the JSON library is. About the XML library, I don't think it even exists.

This is also true for your language definition. Where you expect to find stuffs, it's indeed on another section! People is gonna to go wild with this manual. When you are coding and wanted to consult the manual for the language elements you don't know yet, it took many minutes to go back and forth between sections to actually find the things!

[ghost]

You missed the point.

I have code that needs to be able to process Modula-3 source code.

All that code has to change whenever you modify the language. And every time you add a compiler option, all the code that understands Modula-3 source code has to change to match whatever new thing the compiler does. If you add compiler options and directives that change the semantics of the language, you're really causing a nightmare situation for language tools writers.

No such nightmare would be possible! Just update your tools to ignore compiler switches and compiler directives (pragmas) unknown (to it) and stick with your own legacy subset of the language. This change is only have to be done once.

[mikanystrom]

I think what you're saying doesn't quite make sense. You say the language needs changes, extensions, compiler flags and whatnot. Then you go on to say that the library is lacking. All sorts of basic stuff missing. Which is it? Changing the compiler isn't going to make new libraries write themselves. In fact it will make code churn that will make it harder to find the time to write libraries.

My point is: if your language is imperfect (like the many BASIC dialects I mentioned), you have to invest in documentation and libraries to gain traction. You misinterpreted the whole of my arguments!

Now, there is definitely code to do both XML and JSON in Modula-3. But that's kind of beside the point.

Your distribution is organized in a way make it the most difficult to find things. I know about JSON library not because I found it when searching the distribution hopelessly but because I saw the commits of @demoitem on this repo, only after that I could navigate where the JSON library is. About the XML library, I don't think it even exists.

This is also true for your language definition. Where you expect to find stuffs, it's indeed on another section! People is gonna to go wild with this manual. When you are coding and wanted to consult the manual for the language elements you don't know yet, it took many minutes to go back and forth between sections to actually find the things!

The M3 language specification is very short. 50 pages plus one paragraph. (50 pages was the limit.) This was intentional. You are meant to be able to read it and basically remember the whole thing, and indeed, if you use the language for a few weeks (and look at other people's code), you can easily learn it. There are very few "dark corners" in it. Compare that to how long it takes to learn to become a respectable C++ programmer, or Java programmer, or even Python programmer. Yes it's a bit of hard work, but you only need to do it once.

Sorry I am editing my comment here. I think the level of description you are looking for is actually available. It's a bit old-fashioned though, it's a stack of paper that is tied together with glue in a funny way, they used to call these things "books"...

https://www.amazon.com/Modula-3-Samuel-P-Harbison/dp/0135964040

Paperback available for $14.50.

I think most programming languages are not really learned by working through the language reference, but through tutorial material of some kind, and Harbison's book fills that need.

You could try contacting the author and publisher about releasing the book as open source.

I may not have distributed my XML library... it is wrapped around expat. I'll put it on my list to do.

It's pretty easy to wrap C libraries, by the way. For example, wrapping (a useful subset of) MPFR took an afternoon or so (maybe a long afternoon):

https://github.com/modula3/cm3/tree/master/caltech-other/mpfr/src

[mikanystrom]

You missed the point. I have code that needs to be able to process Modula-3 source code. All that code has to change whenever you modify the language. And every time you add a compiler option, all the code that understands Modula-3 source code has to change to match whatever new thing the compiler does. If you add compiler options and directives that change the semantics of the language, you're really causing a nightmare situation for language tools writers.

No such nightmare would be possible! Just update your tools to ignore compiler switches and compiler directives (pragmas) unknown (to it) and stick with your own legacy subset of the language. This change is only have to be done once.

What you are describing is a worse nightmare, maybe?

A language with optional features where you don't know whether the language tools understand them or not.

Why would you ever want that? That sounds very confusing.

And you have yet to mention any feature actually worthy of such treatment.

BTW if you are looking for things such as macros, it's already trivial to do in Quake. There are probably even examples in the tree. If not I can contribute some. Except for special purposes (using M3 as an embedding language for particular applications for example) I really don't see macros as useful though. Generics are much cleaner and can solve most of the problems you would reach for macros to solve.