RE: open source rpg compiler

Hans said:

>So, what's wrong with the idea? First, let's have a look at how a
>couple of other open-source languages work. Both Perl and Python are
>managed by a central core group of developers who maintain and
>enhance the code. They also review and approve changes submitted by
>others in the general community.

That is one way of doing it.  Another way is the IBM Apache way, where IBM
takes the open source apache, adds some proprietary code, and ships the
closed source, binary only "apache for iSeries".

My proposal is similar. Release the source code, require websphere to run
any offshoot (IBM does not lose $$), get out of the way and let the market
decide.

>Although I'm sure some RPG fans would love to work with the RPG
>compiler source themselves, the community as a whole would not be
>served well by multiple RPG compiler products available, each
>compiling a slightly different version of the language. Most RPG
>shops would still choose to stick with one "official" language.

So, IBM requires that the title and marketing of the RPG offshoot language
make clear that the new language is not RPG.  Does this problem occur with
any other languages where multiple vendors are involved? When a vendor
produces an offshoot, they just call it something else, and the marketplace
decides if the offshoot stays or not.

>And so, with an open source RPG compiler, we'd have a community of
>developers providing patches to the compiler and a central core
>group of developers reviewing, merging code, and testing the
>resulting code to produce an approved RPG release. The lab would
>need to hire additional people to manage that whole process!

yuck!

>So what's my point? First, although some people would love to
>implement their own changes, the community as a whole would not
>welcome a forked language. Second, the time it would take to
>understand the compiler code would be a major barrier for most.
>Thirdly, a knowledge of the compiler internals is not even necessary
>to produce "enhancements" in the form of service programs.

RPG can be enhanced with the following:

Destructor proc associated with a pointer.  When the proc returns, whether
normally or because of an unhandled exception, call the proc with the
pointer as a parm.  This use written proc then deallocs the space, destructs
any internal data.

MONITOR allows CPF message identifiers.

File specs within a proc.  Auto open and close the file on proc entry and
exit.

Namespace support.  Specifics are still up in the air.

User written BIFFs.

Steve Richter