A question on Modula2 vs Free Pascal

[MarkMLl]

Well, to be honest, what I wrote about Lazarus is that others here, mentioned that -and I took it for granted. Nevertheless I do agree that in any case could be used, even as a (very) sophisticated editor. But I just have failed to build it from sources....

Seriously, big mistake. It really is a very /very/ good IDE, and particularly if not doing GUI stuff you don't need to use OO (although I can assure you it helps enormously when working with e.g. threads).

I've been building Lazarus from source on things including NSLU2 "Slugs" for... well certainly 15 years if not more. This really merits a separate "how do I build on Linux distro zzz" thread, but in short /first/ download suitable FPC binaries, /then/ work out how to build FPC, /then/ turn your attention to Lazarus.

MarkMLl

[MarkMLl]

For the time being I am building gm2 (veeeery time consuming ;-) ). So regarding the first part, I am just using the "old way". Regarding the second one (i.e., the forum), I do not think so. Probably, there is nothing...

Let's put that in context: building Lazarus on an ARM-based system with 32Mb RAM and a USB-1 disc took a week. But it worked.

The thing that will really frustrate you- and this applies equally to M2 and FPC- is the lack of any realistic toolkits to build text-oriented interactive programs. There's literally nothing that allows you to interactively construct something like the Turbo or Topspeed IDEs (and I'm sure you know they're related): you have to program up every menu entry and every dialog(ue) by hand.

MarkMLl

[marcov]

I do understand, and I did not mentioned to offend anyone. Eventually, I do agree that what is important is for the job to be done.

No problems, we all have our phases to go through. I regret supporting many oddities of what are now part of the "fpc" and "objfpc" modes long ago. Partially also out of "go our own way" partisanship.

On the other hand, I am not a professional (just a hobbyist) so I have the "luxury" of being "short-sighted" -if you want.

Actually, I was in my M2 days too. I was still into organic chemistry back then.

On top of that I never understood the fundamental ideas behind OO paradigm (perhaps I have not tried enough) and moreover I am more mathematically inclined person -hence the reference to the functional paradigm.

That is easier to answer. Persist and make something big. It is all about managing complexity and actually supporting something for a while, like several years and iterations. In my case it was a M2 program that processed log files for FIDO message networks (pre E-mail stuff) and the associated cost distribution. This is also why my abhorrence of M2 string handling comes from :-)  If the logging programs changed, so did I, and having at least some of the requirements of the program being set externally made me more adaptable to change.

For the time being I am building gm2 (veeeery time consuming ;-) ). So regarding the first part, I am just using the "old way".

I just rebuilt FPC. Unfortunately it was on windows which is 150% of the Linux time, so it went over a minute.....

Regarding the second one (i.e., the forum), I do not think so. Probably, there is nothing...

Another lesson from the log parser. Having support or sounding board is a good thing to have if you venture into a non-trivial project.

[marcov]

The thing that will really frustrate you- and this applies equally to M2 and FPC- is the lack of any realistic toolkits to build text-oriented interactive programs. There's literally nothing that allows you to interactively construct something like the Turbo or Topspeed IDEs (and I'm sure you know they're related): you have to program up every menu entry and every dialog(ue) by hand.

I think I still have topspeed code for a pulldown and submenu (right mouse click) based on Topspeed's module Window.

[MarkMLl]

I regret supporting many oddities of what are now part of the "fpc" and "objfpc" modes long ago. Partially also out of "go our own way" partisanship.

Frankly, I think there's a lot of stuff in the Object Pascal language- possibly mandated by Delphi's former dominance- which should have been generalised rather than hardcoded. Syntax-aware macros or whatever.

But I write that from the position of having been around in the ALGOL days, and seeing things embedded in the language syntax which a few years later were "of course" implemented by libraries.

Let's consider an example. Pascal uses '   ' for strings, Modula-2 uses either '   ' or "   ", neither supports multi-line string literals. There's sporadic debate in the FPC community about using either `   ` or '''   ''' to represent multi-line string literals, but wouldn't a better solution be a way to declare "/this/ sequence defines this derived string type which is closed by /this/ sequence" which would then work with the existing (excellent) polymorphic functions?

We really don't need more cruft added to the language: "FPC 2025" or whatever. What we need is to have Pascal's design revisited, and brought up to date in light of what's been learnt over its 50 year life.

MarkMLl

[DoDep]

Seriously, big mistake. It really is a very /very/ good IDE, and particularly if not doing GUI stuff you don't need to use OO (although I can assure you it helps enormously when working with e.g. threads).

I've been building Lazarus from source on things including NSLU2 "Slugs" for... well certainly 15 years if not more. This really merits a separate "how do I build on Linux distro zzz" thread, but in short /first/ download suitable FPC binaries, /then/ work out how to build FPC, /then/ turn your attention to Lazarus.

MarkMLl

I understand. Obviously, the failure of building I to be attributed to me. My only excuse is that some packages (or even libraries, *.so files) change name from distro to distro.

[DoDep]

The thing that will really frustrate you- and this applies equally to M2 and FPC- is the lack of any realistic toolkits to build text-oriented interactive programs. There's literally nothing that allows you to interactively construct something like the Turbo or Topspeed IDEs (and I'm sure you know they're related): you have to program up every menu entry and every dialog(ue) by hand.

MarkMLl

In the long run I would like to be able to create simple simulations in Mathematics and Science...(that's why I mentioned Raylib binding).

[DoDep]

I just rebuilt FPC. Unfortunately it was on windows which is 150% of the Linux time, so it went over a minute.....

I know... I have built fpc trunk many times in during the last weeks, and usually it takes a couple of minutes in a very modest laptop (linux). But, it seems, GNU M2 is another beast... still compiling, even with
$ make -j 8
:-)

[MarkMLl]

I understand. Obviously, the failure of building I to be attributed to me. My only excuse is that some packages (or even libraries, *.so files) change name from distro to distro.

We'll fix that. The only system that's given me substantial problems was an x86_64-based Android tablet where they'd messed around with what was in libc.

Edited: package naming conventions obviously vary between distreaux. However while the implementation of various libraries often uses a fairly complex something.x.y.z.so convention I'd expect there to be a more stable something.x.so which application programs used: but this will often be in the form of a symlink which- at least on Debian derivatives- is only set up when a development package is installed.

The key here is that symlinks are resolved when a program is linked, so if it's written to use something.x.so the binary will reference something.x.y.z.so and will work even if something.x.so doesn't exist. But linking will fail if something.x.so is a symlink which hasn't been set up...

MarkMLl

[MarkMLl]

I know... I have built fpc trunk many times in during the last weeks, and usually it takes a couple of minutes in a very modest laptop (linux).

Avoid trunk unless instructed, you're currently best off with 3.2.2 (which will build Lazarus 2.2.6). However as I've said: this really is something for a separate thread.

MarkMLl

[marcov]

I regret supporting many oddities of what are now part of the "fpc" and "objfpc" modes long ago. Partially also out of "go our own way" partisanship.

Frankly, I think there's a lot of stuff in the Object Pascal language- possibly mandated by Delphi's former dominance- which should have been generalised rather than hardcoded.

Backwards compatibility is simply key. Both with self and Delphi.  This is very on-topic since it touches the "purity" argument in this thread. You don't want a revision every few years that invalidates existing sources, that is something for compilers that will never amount to anything.

Sometimes living with the warts is better than the alternative.

Yes, a top down design for a legacy free new development system would be different. And it would have been different at any point during FPC's existence, but that is simply not what FPC is about.

Syntax-aware macros or whatever.

Ugh, no. Centralising and internalizing macros is one of the worst mistakes you can make with a language. Even when dressed up as a powertool for meta programming, it still is a statement that your language is a failure.

But anyway, with the unit/module system, macros would be toothless, since headers are not reevaluated when USES/IMPORT a  unit/module. Clean uses are already covered by cross unit inline. So only macros in same source file or .incs would work.

Frankly I would rather remove the current macro facility, and point to an external macro processor like M4 for the very few cases when it is really needed.

But I write that from the position of having been around in the ALGOL days, and seeing things embedded in the language syntax which a few years later were "of course" implemented by libraries.

In an era where global/LTO optimisation is a buzzword, macros are IMHO a dated band-aid.

Let's consider an example. Pascal uses '   ' for strings, Modula-2 uses either '   ' or "   ", neither supports multi-line string literals. There's sporadic debate in the FPC community about using either `   ` or '''   ''' to represent multi-line string literals, but wouldn't a better solution be a way to declare "/this/ sequence defines this derived string type which is closed by /this/ sequence" which would then work with the existing (excellent) polymorphic functions?

First mistake is assuming that every brainfart needs a language extension (a lesson that some of my co-developers IMHO still have to learn, 3 years  hard labour on an ISP helpdesk taught me that every customer request doesn't necessary warrant action even if it sounds reasonable to an uneducated observer (read supervisor)).

But no. Such ploys will undoubtedly only lead to a slippery slope of escape chars to make exceptions to that again (you can imagine the pleas: but what if I want to embed the closing sequence?)

We really don't need more cruft added to the language: "FPC 2025" or whatever. What we need is to have Pascal's design revisited, and brought up to date in light of what's been learnt over its 50 year life.

Not every changement is an improvement.

[MarkMLl]

Backwards compatibility is simply key. Both with self and Delphi.  This is very on-topic since it touches the "purity" argument in this thread. You don't want a revision every few years that invalidates existing sources, that is something for compilers that will never amount to anything.

Agreed, but at that point we should be asking "we've got A and B, how can we unify them into a single concept such that nothing breaks?".

Frankly I would rather remove the current macro facility, and point to an external macro processor like M4 for the very few cases when it is really needed.

Except that something like M4 can't say "the parameter in this context is a Pascal expression, taking into account other macros".

In an era where global/LTO optimisation is a buzzword, macros are IMHO a dated band-aid.

Maybe. But I did say "syntax-aware", not "text-substitution".

First mistake is assuming that every brainfart needs a language extension (a lesson that some of my co-developers IMHO still have to learn, 3 years  hard labour on an ISP helpdesk taught me that every customer request doesn't necessary warrant action even if it sounds reasonable to an uneducated observer (read supervisor)).

But no. Such ploys will undoubtedly only lead to a slippery slope of escape chars to make exceptions to that again (you can imagine the pleas: but what if I want to embed the closing sequence?)

The thing I'm trying to /not/ do is add language extensions, in fact I'd rather remove them. We need a "meta extension" which can define a way of extending the syntax (lexer and parser), novel in the same way that defining that a program should be able to reference an arbitrary number of libraries each containing functions with parenthesised parameters was novel in the 1970s.

Seriously. Something like Pascal's Write() was hardcoded into ALGOL: it took a long time for first Modula-2 to demonstrate how a separately-compiled library could define multiple (distinctly-named) functions and then Turbo Pascal (or an early Delphi?) to do a good job at polymorphic functions.

But we're still stuck with a situation where overloadable operators can't be added, and where a novel delimiter or escape can't be described to the lexer.

MarkMLl

[DoDep]

Same... after of about 2 hours compilation, GNU M2 has been installed, but not only as gm2 (i.e., the compiler) but rather as ./usr/bin/x86_64-unknown-linux-gnu-gcc-13.2.0 (!!!), but also the linker does not work 

Anyway... That's the  point that Markov (if not mistaken) mentioned about the support...

I guess, back to FPC 

[MarkMLl]

Same... after of about 2 hours compilation, GNU M2 has been installed, but not only as gm2 (i.e., the compiler) but rather as ./usr/bin/x86_64-unknown-linux-gnu-gcc-13.2.0 (!!!), but also the linker does not work 

Anyway... That's the  point that Markov (if not mistaken) mentioned about the support...

Just had a quick furkle in Debian. Install gm2 package (gm2-doc is optional) then

Code: [Select]

MODULE hello;

FROM StrIO IMPORT WriteString, WriteLn;

BEGIN
  WriteString('Hello, World!');
  WriteLn
END hello.

then

Code: [Select]

$ gm2 -g -fiso -o hello hello.mod
$ file hello
hello: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=ab803b14822e95a24e3d2c989af8e0496ec6f62f, for GNU/Linux 3.2.0, with debug_info, not stripped
$ ./hello
Hello, World!

The important thing is that that -fiso option doesn't appear in the standard examples but is necessary. I found it at https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1886029.html and from the context I presume that it's being passed to lower-level stages which at the very least use it to select the dialect of library.

On this 'yer Debian system I can see /usr/lib/gcc/x86_64-linux-gnu/12/m2 which contains m2cor, m2iso,  m2log (Logitech?),  m2min  and m2pim. All of these except the Logitech one have SYSTEM.def and SYSTEM.mod, which implies that anybody thinking they can recompile Logitech (or any other popular implementation including TopSpeed and FTL) is SOL.

I'm not encouraging you to assume this is usable, but neither am I saying it's unusable: our other comments in this thread apply.

MarkMLl

[DoDep]

Just had a quick furkle in Debian. Install gm2 package (gm2-doc is optional) then

I do not know... perhaps GNU M2 is polished just on Debian. I might be wrong of course. But even so, on the other hand I was thinking of two things:
a) whether it is maintained (or so and so)
b) that it would be pain in the... to compile it each and every time a version is out (~2 hours and I am not a Gentoo user  )