PL/I and OOP - Programming Languages

"David Frank" <dave_frank@hotmail.com> wrote in message
news:44fbe03e$0$12071$ec3e2dad@news.usenetmonster.com...[color=blue]
>
> "robin" <robin_v@bigpond.com> wrote in message
> news:cjLKg.22641$rP1.15366@news-server.bigpond.net.au...[color=green]
> > "David Frank" <dave_frank@hotmail.com> wrote in message
> > news:44faac99$0$20236$ec3e2dad@news.usenetmonster.com...[color=darkred]
> >>
> >> However, more importantly as I just posted in another topic, there isnt a
> >> compiler that meets what OUGHT to be everyone's MINIMUM criteria..
> >>
> >> 1. CURRENTLY being sold[/color]
> >
> > It is.
> >[color=darkred]
> >> 2. for a O.S. thats being sold[/color]
> >
> > it is. (Frank thinks that Widows is not sold any more)
> >[color=darkred]
> >> 3. for a computer thats being sold[/color]
> >
> > It is. (Frank thinks that Intel machines are not being sold any more)
> >[color=darkred]
> >> 4. PRICE < $3000[/color]
> >
> > Try free.[/color]
>
> Saying "Try free" is yet another attempt at obfuscation.
> Whats sad is how your peers accept your deceitful attempts
> (to make a silk purse out of a sow's ear) without complaint.[/color]

Why is it that you are incapable of remembering anything
for more than 5 minutes.

You have read here many times that DR PL/I is free for non-
commercial use.
Also, you have read here many times that Kednos PL/I
is available free for non-commercial use.

"David Frank" <dave_frank@hotmail.com> wrote in message
news:44fbdbe8$0$12080$ec3e2dad@news.usenetmonster.com...[color=blue]
>
> Your main-frame defense for PL/I is understandable since how many ADA
> compilers are there for Windows < $3000 ( zero would be my guess)
>[/color]
This conversation is not about Ada. In fact, despite the name on my email,
I no longer have a company involved in Ada. Rather, I am now devoting
full-time to being a university professor, focused primarily on software
engineering.

I don't want to get into an argument with you. However, I do need to correct
your last statement. Ada is an ISO standard. A free, fully functional
compiler,
is available for free download. It is built over the GCC standard and licensed
under the GPL Copyleft agreements. There are no fees attached to its use.
It runs on a large number of platforms, including Windows, Linux, and most
Unix-like environments. There is also a version called A# which supports
the Microsoft .NET platform. Ada is now in its newest standard, Ada 2005,
and has continued to evolve toward a better and better language.

My original inquiry has to do with the evolution of PL/I, especially its
support for OOP. I am not getting a lot of answers on that issue. I
simply want to know whether there is an OOP implementation of PL/I,
not get into a fight about whether it is or is not a good language.

Richard Riehle

Henrik,

Excellent reply. I will take a look at the OO extensions.

As to interfaces, I agree with you that this is a powerful and
important innovation in program language design. One of the
most important contributions of Java was the interface. Other
languages are adding that feature as they are being revised.

However, I am not happy that Java has no simple way to include
functions (methods) as parameters to other methods. This was
corrected by the design of C#. I really like to be able to use
a functional style of programming, especially when doing math
programming. I think PL/I does support this feature, but have
not tried it yet.

Richard Riehle

======================================================
<henrik.sorensen@balcab.ch> wrote in message
news:43d1c$44fbf039$5448c618$19796@news.hispeed.ch...[color=blue]
> [email]adaworks@sbcglobal.net[/email] wrote:
>[color=green]
>> I am about to teach my class in comparative programming
>> languages again next Quarter.
>>
>> I have reviewed the FAQ site and spent more time than is
>> probably appropriate examining PL/I to see if it still qualifies
>> as a topic deserving of any serious attention in the class.[/color]
> it does, it does :-)
>[color=green]
>>
>> When compared to most other contemporary languages I
>> still find it lacking -- especially in OOP features.[/color]
> One feature, I am considering putting into the pl1gcc version of PL/I would
> be the compiler assisted support of 'interfaces'.
> IMO, object inheritance without an explicit defined interface, is heavily
> overrated, but interfaces, as done in eg. Java, I find very cool and
> extremely useful.
> But this will have to come after the current language level can actually be
> used for real programs.
>[color=green]
>>
>> In particular, I am still unable to determine whether there is
>> an operational PL/I implementation that supports object-oriented
>> programming. There seems to be some position papers and
>> discussions about this, but I cannot confirm the existence of
>> an OOP version of PL/I.[/color]
>
> You might want to check out:
> Object Oriented Extension generator by Patrick Senti.
> I dont know if Patrick has an official website for it, but he has graciously
> released his work under GPLv2 license, and pl1gcc are carrying a copy of
> the code:
> pl1gcc.cvs.sourceforge.net/pl1gcc/gcc/gcc/pl1/Extra/contributed/oopli-alpha/
>
>[color=green]
>>
>> I would be happy to include it in my discussion of OOP languages
>> if there is an real implementation out there somewhere.[/color]
>
> Have you had a look at the latest version of the IBM Enterprise compiler,
> here some new features that makes encapsulation easier, are implemented ?
>[color=green]
>>
>> Richard Riehle[/color]
> Henrik Sorensen
>
> pl1gcc.sourceforge.net[/color]

"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:tnUKg.33727$8j3.4895@twister.nyroc.rr.com...[color=blue]
>
> I don't know much about OOP, though I'd like to learn more. I think the idea
> has suffered from bad c++ implementations that depend on "name mangling" to
> implement roughly the equivalent of PL/I "GENERIC" functions. (long URL
> follows).
>[/color]
Peter. C++ is one of the ugliest languages ever invented. One has to
jump through a lot of hoops to get anything right. It is highly error-prone,
and many of the features are designed to compensate for the lack of
clarity in other features.

It always suprises me that anyone would deliberately use a language that
is inherently error-prone and expect an outcome that is error-free.

There are good language designs for OOP. Try Eiffel.

Richard Riehle

Peter Flass wrote:[color=blue]
> [email]henrik.sorensen@balcab.ch[/email] wrote:
>[color=green]
>>
>> One feature, I am considering putting into the pl1gcc version of PL/I
>> would
>> be the compiler assisted support of 'interfaces'. IMO, object
>> inheritance without an explicit defined interface, is heavily
>> overrated, but interfaces, as done in eg. Java, I find very cool and
>> extremely useful.
>> But this will have to come after the current language level can
>> actually be
>> used for real programs.[/color]
>
>
> I don't know much about OOP, though I'd like to learn more. I think the
> idea has suffered from bad c++ implementations that depend on "name
> mangling" to implement roughly the equivalent of PL/I "GENERIC"
> functions. (long URL follows).
>
> [url]http://books.google.com/books?vid=ISBN1558604960&id=h34d_jr2iikC&pg=PA1&lpg=PA1&dq=%22linkers+and+loaders%22&sig=KUrIeTY_eZmGJHw3aU_I0k_TPMk[/url]
>
>
> I believe Multics may have had better method of handling this stuff with
> a binder that could actually recognize arguments and make the choice of
> what to link without all the nonsense.
>[/color]
You're confusing the language with the operating system. The linker is
part of the operating system and the reason for the name mangling is
compatibility with the operating system. Perhaps Multics did it better,
but Multics is an operating system, not a language.

In order to link separately-compiled object files with identically-named
generic procedures together, the linker needs to be able to associate
each invocation of a generic procedure with the proper definition from
among the identically-named procedure definitions. Without encoding the
procedure argument types as part of the name of the procedure, the only
other way to communicate that information to the linker is to provide a
mechanism to keep the (pre-compiled) symbol table(s) of the generic
procedure definitions and make it available during compilation and
possibly linking of any procedures that invoke those generics. It would
also still be necessary to generate a unique name for each variant of
each generic procedure, something already accomplished by the name mangling.
[color=blue]
> If I ever get a chance, I'd like to experiment with OO PL/I, but I think
> I have to pick up some background first.
>[/color]

Bob Lidral
lidral at alum dot mit dot edu

[email]adaworks@sbcglobal.net[/email] wrote:[color=blue]
> Henrik,
>
> Excellent reply. I will take a look at the OO extensions.
>
> As to interfaces, I agree with you that this is a powerful and
> important innovation in program language design. One of the
> most important contributions of Java was the interface. Other
> languages are adding that feature as they are being revised.
>
> However, I am not happy that Java has no simple way to include
> functions (methods) as parameters to other methods. This was
> corrected by the design of C#. I really like to be able to use
> a functional style of programming, especially when doing math
> programming. I think PL/I does support this feature, but have
> not tried it yet.
>[/color]

Yes. it's had this since day one. Years ago I couldn't understand why
you can't pass a builtin function as an argument.

Bob Lidral wrote:
[color=blue]
> Peter Flass wrote:
>[color=green]
>> [email]henrik.sorensen@balcab.ch[/email] wrote:
>>[color=darkred]
>>>
>>> One feature, I am considering putting into the pl1gcc version of PL/I
>>> would
>>> be the compiler assisted support of 'interfaces'. IMO, object
>>> inheritance without an explicit defined interface, is heavily
>>> overrated, but interfaces, as done in eg. Java, I find very cool and
>>> extremely useful.
>>> But this will have to come after the current language level can
>>> actually be
>>> used for real programs.[/color]
>>
>>
>>
>> I don't know much about OOP, though I'd like to learn more. I think
>> the idea has suffered from bad c++ implementations that depend on
>> "name mangling" to implement roughly the equivalent of PL/I "GENERIC"
>> functions. (long URL follows).
>>
>> [url]http://books.google.com/books?vid=ISBN1558604960&id=h34d_jr2iikC&pg=PA1&lpg=PA1&dq=%22linkers+and+loaders%22&sig=KUrIeTY_eZmGJHw3aU_I0k_TPMk[/url]
>>
>>
>> I believe Multics may have had better method of handling this stuff
>> with a binder that could actually recognize arguments and make the
>> choice of what to link without all the nonsense.
>>[/color]
> You're confusing the language with the operating system. The linker is
> part of the operating system and the reason for the name mangling is
> compatibility with the operating system. Perhaps Multics did it better,
> but Multics is an operating system, not a language.[/color]

Right. It's not confusion, but lack of understanding as to why they
didn't write their own linker. I can see what they did at first. As I
understand it, C++ originally generated C, so it was more of a
preprocessor than a language by itself, but as it developed later it
would seem to have needed to have a linker written for it. Of course,
neither C nor (AIUI) C++ understand what argument descriptors are, but
it would seem a no-brainer to have the linker use real descriptors
instead of "name mangling" to achieve what is needed. Naturally a C++
linker would have to provide backward-compatibility with standard
linkers. Seems like they only did half the job and gave up.
[color=blue]
>
> In order to link separately-compiled object files with identically-named
> generic procedures together, the linker needs to be able to associate
> each invocation of a generic procedure with the proper definition from
> among the identically-named procedure definitions. Without encoding the
> procedure argument types as part of the name of the procedure, the only
> other way to communicate that information to the linker is to provide a
> mechanism to keep the (pre-compiled) symbol table(s) of the generic
> procedure definitions and make it available during compilation and
> possibly linking of any procedures that invoke those generics. It would
> also still be necessary to generate a unique name for each variant of
> each generic procedure, something already accomplished by the name
> mangling.[/color]

Sounds like we're almost on the same page; at least I seem to have
understood that much. You don't need the whole symbol table, just data
for the external entries and their arguments.

[email]adaworks@sbcglobal.net[/email] wrote:
[color=blue]
> Henrik,
>
> Excellent reply. I will take a look at the OO extensions.[/color]
the code is pretty much left in its initial state as delivered by Patrick
Senti. I would very much appreciate any feedback you might have.
[color=blue]
>
> As to interfaces, I agree with you that this is a powerful and
> important innovation in program language design. One of the
> most important contributions of Java was the interface. Other
> languages are adding that feature as they are being revised.[/color]
including PL/I :-)

Well in principle, PL/I supports 'interfaces', but you will have to code it
by hand.

You could do:

dcl 1 myInterface
, 3 openIt entry variable
, 3 readIt entry variable
, 3 closeIt entry variable
;


oroc(name);
open file(....);
end o;

r: proc(...);
read file(...);
end r;

c: proc(...);
close file(...);
end c;

initMyInterfaceroc;
myInterface.openIt=o;
myInterface.readIt=r;
myInterface.closeIt=c;
end initMyInterface;

and then add some way to share whatever context information you need, and
now the structure myInterface can be passed as parameter to any procedure
or function, but you really want some help from the compiler to do this.

[color=blue]
>
> However, I am not happy that Java has no simple way to include
> functions (methods) as parameters to other methods. This was
> corrected by the design of C#. I really like to be able to use
> a functional style of programming, especially when doing math
> programming. I think PL/I does support this feature, but have
> not tried it yet.[/color]
look into the GENERIC declares, and into the RETURNS option of the procedure
statement.

[color=blue]
> Richard Riehle[/color]
Henrik

Peter Flass wrote:[color=blue]
> Bob Lidral wrote:
>[color=green]
>> Peter Flass wrote:
>>[color=darkred]
>>> [email]henrik.sorensen@balcab.ch[/email] wrote:
>>>
>>>>
>>>> One feature, I am considering putting into the pl1gcc version of
>>>> PL/I would
>>>> be the compiler assisted support of 'interfaces'. IMO, object
>>>> inheritance without an explicit defined interface, is heavily
>>>> overrated, but interfaces, as done in eg. Java, I find very cool and
>>>> extremely useful.
>>>> But this will have to come after the current language level can
>>>> actually be
>>>> used for real programs.
>>>
>>>
>>>
>>>
>>> I don't know much about OOP, though I'd like to learn more. I think
>>> the idea has suffered from bad c++ implementations that depend on
>>> "name mangling" to implement roughly the equivalent of PL/I "GENERIC"
>>> functions. (long URL follows).
>>>
>>> [url]http://books.google.com/books?vid=ISBN1558604960&id=h34d_jr2iikC&pg=PA1&lpg=PA1&dq=%22linkers+and+loaders%22&sig=KUrIeTY_eZmGJHw3aU_I0k_TPMk[/url]
>>>
>>>
>>> I believe Multics may have had better method of handling this stuff
>>> with a binder that could actually recognize arguments and make the
>>> choice of what to link without all the nonsense.
>>>[/color]
>> You're confusing the language with the operating system. The linker
>> is part of the operating system and the reason for the name mangling
>> is compatibility with the operating system. Perhaps Multics did it
>> better, but Multics is an operating system, not a language.[/color]
>
>
> Right. It's not confusion, but lack of understanding as to why they
> didn't write their own linker. I can see what they did at first. As I
> understand it, C++ originally generated C, so it was more of a
> preprocessor than a language by itself, but as it developed later it
> would seem to have needed to have a linker written for it. Of course,
> neither C nor (AIUI) C++ understand what argument descriptors are, but
> it would seem a no-brainer to have the linker use real descriptors
> instead of "name mangling" to achieve what is needed. Naturally a C++
> linker would have to provide backward-compatibility with standard
> linkers. Seems like they only did half the job and gave up.
>[/color]
FWIW: DR/DOS PL/I provides its own linker (I guess because of the
non-standard format of their object modules. But, at least it allows
one to write assembly language subroutines for inclusion.)[color=blue][color=green]
>>
>> In order to link separately-compiled object files with
>> identically-named generic procedures together, the linker needs to be
>> able to associate each invocation of a generic procedure with the
>> proper definition from among the identically-named procedure
>> definitions. Without encoding the procedure argument types as part of
>> the name of the procedure, the only other way to communicate that
>> information to the linker is to provide a mechanism to keep the
>> (pre-compiled) symbol table(s) of the generic procedure definitions
>> and make it available during compilation and possibly linking of any
>> procedures that invoke those generics. It would also still be
>> necessary to generate a unique name for each variant of each generic
>> procedure, something already accomplished by the name mangling.[/color]
>
>
> Sounds like we're almost on the same page; at least I seem to have
> understood that much. You don't need the whole symbol table, just data
> for the external entries and their arguments.
>[/color]