On Saturday, December 10, 2022 at 12:42:25 PM UTC-3, Vincent Coen wrote:
Hello KTSnowy!
Saturday December 10 2022 05:32, KTSnowy (The Web Dev Fox) wrote to All:
On Tuesday, November 29, 2022 at 12:14:58 PM UTC-3, JM wrote:
A terça-feira, 29 de novembro de 2022 à(s) 15:13:50 UTC, JM
escreveu:
A segunda-feira, 28 de novembro de 2022 à(s) 18:45:16 UTC,
keit...@gmail.com escreveu:
On Monday, November 28, 2022 at 7:22:42 AM UTC-3, JM wrote:
Interesting. Good job. Waiting for the final version.
Regards,
I'll make another announcement here when we get things working
and ready to test with COBOL source code.
In the meantime let me know if there's something that you'd like
to see implemented in the Otterkit compiler.
Cobol is essentially a backend language, but for any modern
language to be successful, it has to have easy access to create GUI
applications.
In .NET environment, WinForms integrated with Cobol it would be
the way.. + SQL access!
By SQL access so you mean IBM's EXEC SQL statement?
IBM did not design it and the EXEC SQL in supported by most if not all
RDBMS products including Mysql / mariadb, Postgres, Oracle, DB/2, MF SQL server, and many others.
All are serviced by a pre-compiler that you feed the .scb sources to and
out comes a .cbl to pass to the Cobol compiler.
IT is a pity that there is no universal pre-compiler available that
supports more than one of these different RDB products but I was going to upgrade the JC pre-compiler (written in Cobol) but other programming requirements have gotten in the way..
Adding new statements to Otterkit is quite easy with the current architecture, so we could definitely support it in the future when the compiler gets to a more stable state.
As some one has said a major requirement for a new compiler is full support for a gui interface for all supported platform and where possible a link into the SCREEN SECTION and accept, display accordingly.
This may be a bit of an ask i.e., supporting say Linux / *Nix and Windows with the same product.
Vincent
Hey Vincent,
As some one has said a major requirement for a new compiler is full support >for a gui interface for all supported platform and where possible a link
into the SCREEN SECTION and accept, display accordingly.
This may be a bit of an ask i.e., supporting say Linux / *Nix and Windows >with the same product.
One thing that we strongly disagree with in some current COBOL compilers is the apparent
need to embed additional functionality directly as compiler or COBOL language extensions.
We're trying a different approach and we're trying to make it easier to add and create external
libraries, COBOL 2022 has enough features and functionality to be able to write libraries and
frameworks, specially with it's OOP features. Having to embed extra functionality into the
language can easily make the compiler bloated and not cross OS, specially with GUI related stuff.
Yes, we're going to fully support the screen section and it's features from the 2022 standard,
but embedding any GUI framework into it would be a REALLY BAD idea. GUI is most of the time
not a cross OS thing, and most cross OS frameworks usually don't feel "native" to any OS.
Embedding any WinForms related functionality into the screen section itself would instantly
also make the compiler not compatible with Linux and macOS, and that would be quite bad.
Which is why we strongly believe that for Otterkit to work properly and have a place in a modern
ecosystem we need to make it easier to use and create COBOL libraries. It is a much better option
to support COBOL bindings for each OS's native GUI framework and let the user choose which one
to use and work with it as an added library or framework (Like every other ecosystem is doing it) than
directly embedding it into the language. It's also much easier to keep the compiler cross OS like this,
since each library and framework can be added as needed for each OS.
I was also thinking about including the EXEC SQL statement's functionality as a library function instead
of directly into the language as an actual statement. This seems much more reasonable today in 2022
and wouldn't be that much of a change. It will be much easier maintaining an SQL library for COBOL than
adding a specific RDBMS into the runtime itself to be able to run SQL statements. Supporting multiple
RDBMS systems would also be easier with an external library and not having to touch the compiler.
Something like: FUNCTION EXEC-SQL( "PostgreSQL" alphanumeric-literal ).
The first argument is the RDBMS to use, and the alphanumeric-literal would contain the SQL statements passed to the RDBMS.
The same idea could be applied to any GUI framework, just provide COBOL bindings and expose any
GUI framework specific functions, classes, methods, etc as COBOL functions, classes and methods.
Now suddenly the work on the compiler will be much simpler and won't have to deviate much if at all
from the standard. Any added functionality or complexity is contained in external libraries.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)