A question on Modula2 vs Free Pascal

[MarkMLl]

Yeah, at least the ISO part 1 version included in GCC 13 and up is really nice. (I build my own GCC compilers, currently GCC 15 snapshot 20240602.) Though, I hope they will add ISO part 2 (classes) and ISO part 3 (generics) soon.

Is there any legal way of getting the complete ISO Modula-2 (parts 1, 2 and 3) BNF definition without buying the ISO documents ? I mean, the BNF only.

Daniel

I suggest asking on the appropriate GCC-related mailing list.

However I'd add that an unembellished (E)BNF description of a language should, as a statement  of fact, be uncopyrightable.

MarkMLl

[Pasqualish]

GNU Modula-2 does not have a forum but there is a mailing list and the person who is writing the compiler is on it.

https://lists.nongnu.org/mailman/listinfo/gm2/

[MarkMLl]

GNU Modula-2 does not have a forum but there is a mailing list and the person who is writing the compiler is on it.

https://lists.nongnu.org/mailman/listinfo/gm2/

We know, but for the last couple of decades Gaius's M2 implementation has been in limbo. Now that the overall GNU Compiler Collection project is taking it a bit more seriously there are presumably public resources that they use as reference when writing test cases etc.

MarkMLl

[Thaddy]

Mark, you are right: in this case "should be" can be replaced with "is not". "copyrightable"

[MarkMLl]

Mark, you are right: in this case "should be" can be replaced with "is not". "copyrightable"

I suggest that the situation is complicated when considering the originator of a normative standard.

MarkMLl

[Pasqualish]

I echo what Marco said, from the position of also using (and selling) other variants. Taking his points about case-sensitivity and improved modularisation as read,

a) The syntax is different: Pascal used if-then-else while M2 uses IF-THEN-ELSE-END and so on.

The nice thing about an END (also in Ruby/Crystal) is that if-then-else is typically if-then-begin-end-else or if-then-else-begin-end or if-then-begin-end-else-begin-end  (same issue for WHILE)

[Pasqualish]

Modula2 is just procedural, that's it. Maybe Gm2 has some rudimentary (M3?) OO nowadays, but probably not up to the Delphi level.

There doesn't appear to be any additions in the current compiler over what was specified by Wirth in his books or in the part of the ISO standard that was only procedural:
 
ISO/IEC 10514-1:1996 - Modula-2 (Base Language) ( published on 1996-06-01 )

I saw somewhere there was a plan to implement what was specified in an effort that was titled Modula-2 Reloaded ( http://modula-2.net/m2r10/ ) . But I don't see any big changes to the language in that effort. They do mention: "from Oberon: (extensible record types)" but also say "We aimed for the ability to replace C as a systems implementation language." and mention removing things from the language.

Have not seen any plans for GNU Modula-2 to implement the OO or generic parts of the ISO standard:

ISO/IEC 10514-2:1998 - Modula-2 (OO extension) ( published on 1998-12-19 )
ISO/IEC 10514-3:1998 - Modula-2 (Generic extension) ( published on 1998-12-19 )

http://sc22wg13.twi.tudelft.nl

Doesn't appear to be any syntax for user generated exceptions which are a nice part of modern languages.

[duralast]

I echo what Marco said, from the position of also using (and selling) other variants. Taking his points about case-sensitivity and improved modularisation as read,

a) The syntax is different: Pascal used if-then-else while M2 uses IF-THEN-ELSE-END and so on.

The nice thing about an END (also in Ruby/Crystal) is that if-then-else is typically if-then-begin-end-else or if-then-else-begin-end or if-then-begin-end-else-begin-end  (same issue for WHILE)

Ada uses end too

Code: [Select]

If then
elsif then
else
end if

if then
elsif then
  if then
   else
  end if
elsif then
end if


[MarkMLl]

The nice thing about an END (also in Ruby/Crystal) is that if-then-else is typically if-then-begin-end-else or if-then-else-begin-end or if-then-begin-end-else-begin-end  (same issue for WHILE)

No, begin is an error there. It's if-then-end or if-then-else-end etc., and there's also a minor difference in the case statement.

MarkMLl

[MarkMLl]

Ada uses end too

Yes, but the heritage is different: Ada's root languages were ALGOL-60 and Pascal, but- unlike Pascal- it took on board the problems caused by ALGOL-60's "dangling else".

It's also worth mentioning that the authors of the "minority report" criticising ALGOL-68 were prominent in Ada's early design.

I've seen a couple of people with substantial industry experience writing approvingly of Ada over the last few years, and generally preferring it over what C++ etc. have become. However a criticism that was made was that available implementations were not good at linking with the vast number of available C-based libraries, and in that context I have to highlight FPC's shortcomings when it comes to linking with OO C++.

MarkMLl

[marcov]

However a criticism that was made was that available implementations were not good at linking with the vast number of available C-based libraries, and in that context I have to highlight FPC's shortcomings when it comes to linking with OO C++.

There is no OO C++. From compiler to compiler, version to version ABIs and mangling change.

[MarkMLl]

There is no OO C++. From compiler to compiler, version to version ABIs and mangling change.

Not my problem.

The public perception of FPC is damaged enormously when developers say things like "tell the outside library that they need to continue supporting their C version, rather than moving to a class-based interface".

MarkMLl

[440bx]

I'm going to tread carefully here because my knowledge of C++ is rather deficient (barely enough to understand _most_ of the code.)

That said, GdiPlus is all based on C++ classes/objects and both Delphi and FPC can use GdiPlus.  It seems to me that indicates a well designed C++ class is usable by FPC. 

What I'm saying here is, I don't think it is right to blame FPC for not supporting C++ classes, it does, otherwise it couldn't use GdiPlus.  It seems the problem(s) reside with the way the C++ classes are, in some cases, designed.

[marcov]

That said, GdiPlus is all based on C++ classes/objects and both Delphi and FPC can use GdiPlus.  It seems to me that indicates a well designed C++ class is usable by FPC. 

Being written in C++, doesn't prevent the C++ programmer defining a procedural or COM interface. This is about interfacing on unvarnished C++ level, which two different C++ compilers mostly even can't.

Anyway, for interested people Rudi Velthuis did some work on it once, it is possible for a specific compiler/version if you just want to. It is simply not supported in a blanket, general case.

[MarkMLl]

What I'm saying here is, I don't think it is right to blame FPC for not supporting C++ classes, it does, otherwise it couldn't use GdiPlus.  It seems the problem(s) reside with the way the C++ classes are, in some cases, designed.

Well, that's as may be but the last time I discussed this Sven said it was a no-no.

I can't remember who made the suggestion that library maintainers should continue to support a C API even if their preference was C++, and the forum's search isn't very helpful.

Having said that, I agree that C is a /lingua/ /franca/ as far as APIs are concerned, and that any project that moves away from C risks limiting its uptake by users of other languages. Unfortunately, precisely the same applies to anybody who chooses to express an API in Modula-2, Ada or Object Pascal.

MarkMLl