A question on Modula2 vs Free Pascal

[440bx]

@marcov & @MarkMLI,

I remembered seeing an interface/bindings to GDI Plus sometime.  At the time I found it I just had a quick look at it.  A number of people have created bindings for Delphi and FPC to gdiplus. 

I just had another look at the version I played with long ago, it was created by Erik Van Bilsen (there is also code/definitions in there from the JEDI group) and, there is a set of COM interfaces on top of the gdip API,  basically what @marcov mentioned as a possible interface.

[gidesa]

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".

Indeed a "quite" successfull language as Python as no problem at all with C++ libraries, because simply it has no native mechanism to implement the bindings.
The use of C++ libraries (ex. Tensorflow, Opencv, and many many others) is based on a special library version (wrapper), with appropriate hooks to internal Python interpreter functions. All, interpreter and wrapper,  written ... in C++, of course! :-)
So all depend from complex and subtle reasons: today all the effort to write Python bindings is very well accepted from same authors of libraries, because the users base is big. Instead, it's totally rejected for Pascal, that has a little users base.

[gidesa]

I remembered seeing an interface/bindings to GDI Plus sometime.  At the time I found it I just had a quick look at it.  A number of people have created bindings for Delphi and FPC to gdiplus. 

Indeed the gdiplus.dll exports a normal C API (see attached dumpbin log). So it isn't an example of C++ to Pascal bindings.

[marcov]

The use of C++ libraries (ex. Tensorflow, Opencv, and many many others) is based on a special library version (wrapper), with appropriate hooks to internal Python interpreter functions. All, interpreter and wrapper,  written ... in C++, of course! :-)

Maybe being compiled with the same compiler also saves the mangling.

The test would be to interface a library by another C++ compiler than the Python interpreter uses. Keep in mind that on e.g. Windows LLVM, GCC and MSVC are all commonly used.

[MarkMLl]

Indeed a "quite" successfull language as Python as no problem at all with C++ libraries, because simply it has no native mechanism to implement the bindings.
The use of C++ libraries (ex. Tensorflow, Opencv, and many many others) is based on a special library version (wrapper), with appropriate hooks to internal Python interpreter functions. All, interpreter and wrapper,  written ... in C++, of course! :-)
So all depend from complex and subtle reasons: today all the effort to write Python bindings is very well accepted from same authors of libraries, because the users base is big. Instead, it's totally rejected for Pascal, that has a little users base.

I loathe Python's syntax, which could only have been conceived by somebody too inexperienced to remember FORTRAN's "(almost) everything starts in column 7" rule.

Having said which, its success as both an extension and implementation language speaks for itself.

I wrote some stuff a couple of years ago which could run a Python script using either v2 or v3, statically or dynamically linked, with the intention of replacing an Electron GUI that nobody knew how to debug. I was exceedingly impressed by the quality of the Python documentation, but ultimately hit a wall caused by FPC's lack of direct support for C-style variadic functions.

Python has, to all intents and purposes, supplanted Perl, Lua, Basic, C# and the rest as an extension language. It quite simply /cannot/ be ignored, however much we might like to do so.

MarkMLl

[gidesa]

Maybe being compiled with the same compiler also saves the mangling.

The test would be to interface a library by another C++ compiler than the Python interpreter uses. Keep in mind that on e.g. Windows LLVM, GCC and MSVC are all commonly used.

Yes, it's mandatory to use compatible compilers for interpreter and wrapper.
But the point is that Python hasn't something as "external" definitions in Pascal. If you want to bind an external library, you have to handwrite a specific wrapper in C/C++ (or also in Pascal, if there is a C API).
But so many people happily write them   

[gidesa]

Having said which, its success as both an extension and implementation language speaks for itself.

Python has, to all intents and purposes, supplanted Perl, Lua, Basic, C# and the rest as an extension language. It quite simply /cannot/ be ignored, however much we might like to do so.

Yes, Python cannot be ignored, especially if one write a library and wants the maximum number of users.
So it's an example of language/implementation with many limits, but so largely supported, despite the important effort to interface with external code.
Compare to the powerful native foreign functions interface of Pascal, but also Lua, C#, and even old Visual Basic! Of course only for C style API.

[marcov]

I mostly see PHP as scripting language actually. But probably because we are mostly communicating to intraweb like factory systems that are web oriented to begin with.

I don't do much end user deployment anymore, but I can imagine that Python has as major disadvantage that it is not default on Windows. You don't want to explain setting it up to a user.

I do use Python with Kicad, but basically I just generate long python scripts from a Lazarus app to mass instantiate copies of a basic (led) cell and position them  in a matrix :-)

[Pasqualish]

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

I was giving what you have to write in Pascal.

[marcov]

I was giving what you have to write in Pascal.

True, but there is Modula-2 in the thread title.

[MarkMLl]

True, but there is Modula-2 in the thread title.

And the paragraph itself was highly ambiguous.

MarkMLl

[PascalDragon]

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.

The problem is that a C++ interface is a detriment for any language that isn't C++. It would even be an issue with a different C++ compiler! You can't for example simply use a MSVC compiled C++ library inside a GCC compiled program cause the mangling and ABI is simply not compatible (with clang however it works, cause they provide a MSVC compatible ABI on Windows).

While some of this could be handled by FPC's cppclass the problem is that C++ has some concepts that simply don't exist in (Object) Pascal, like overloads for the dereferentiation or indexing operators or const vs. non-const methods. Then there's also C++ templates that would need to be supported one way or the other as most modern APIs rely on them.
And if the involved C++ compiler made some ABI changes between versions then things would also break on the FPC side. The C ABI is simply much more stable.

[mercurhyo]

interesting point of view at at this link about freepascal vs oberon+ wich is successor of modula

https://www.osnews.com/story/137572/oberon-system-3-compatible-with-the-oberon-compiler-and-ide/

[MarkMLl]

The problem is that a C++ interface is a detriment for any language that isn't C++. It would even be an issue with a different C++ compiler! You can't for example simply use a MSVC compiled C++ library inside a GCC compiled program cause the mangling and ABI is simply not compatible (with clang however it works, cause they provide a MSVC compatible ABI on Windows).

While some of this could be handled by FPC's cppclass the problem is that C++ has some concepts that simply don't exist in (Object) Pascal, like overloads for the dereferentiation or indexing operators or const vs. non-const methods. Then there's also C++ templates that would need to be supported one way or the other as most modern APIs rely on them.
And if the involved C++ compiler made some ABI changes between versions then things would also break on the FPC side. The C ABI is simply much more stable.

On the one hand, and from the POV of FPC as a project and community, I agree with you. I also feel that for library maintainers to mandate an API with limited portability expressed in a language with dubious stability does them little credit.

On the other hand, from the POV of the broader software community and industry, Object Pascal's inability or refusal to conform to what are today seen as fundamental expectations is a major factor in its dismissal: and that's particularly the case when languages such as Python do make an attempt to comply.

I find myself looking at the symptoms of the 2000/10s software crisis, of which the UK's Horizon scandal is just one, and wonder whether Pascal's robustness and rigour could have helped. I then find myself wondering whether it would have been given a chance to prove itself.

Please don't comment to that paragraph here, I'm inclined to start a separate thread in the "other" topic for it.

MarkMLl

[marcov]

On the other hand, from the POV of the broader software community and industry, Object Pascal's inability or refusal to conform to what are today seen as fundamental expectations is a major factor in its dismissal: and that's particularly the case when languages such as Python do make an attempt to comply.

IMHO it is just a stick from popular tools to beat less popular ones, while their own negatives (performance, major versions, package tools security risks) are played down because, "hey we are popular!". Self fulfilling prophesies.