f



PL/I and OOP

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.

When compared to most other contemporary languages I
still find it lacking -- especially in OOP features.

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.

I would be happy to include it in my discussion of OOP languages
if there is an real implementation out there somewhere.

Richard Riehle 


0
adaworks2 (748)
9/2/2006 11:22:59 PM
comp.lang.pl1 1741 articles. 0 followers. Post Follow

225 Replies
1012 Views

Similar Articles

[PageSpeed] 12

<adaworks@sbcglobal.net> wrote in message 
news:nnoKg.14500$%j7.1873@newssvr29.news.prodigy.net...
>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.
>
> When compared to most other contemporary languages I
> still find it lacking -- especially in OOP features.
>
> 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.
>
> I would be happy to include it in my discussion of OOP languages
> if there is an real implementation out there somewhere.
>
> Richard Riehle


Other than OOP features,  how about listing the 5 most important  features 
it lacks
(in your opinion)..

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
2. for a  O.S.  thats being sold
3. for a computer thats being sold
4. PRICE < $3000

I think those are reasons enuf to ignore PL/I



0
dave_frank (2243)
9/3/2006 10:17:46 AM
"David Frank" <dave_frank@hotmail.com> wrote in message
news:44faac99$0$20236$ec3e2dad@news.usenetmonster.com...
>
> 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

It is.

> 2. for a  O.S.  thats being sold

it is. (Frank thinks that Widows is not sold any more)

> 3. for a computer thats being sold

It is. (Frank thinks that Intel machines are not being sold any more)

> 4. PRICE < $3000

Try free.

> I think those are reasons enuf to ignore PL/I

I think that Frank's stupid posts are reason enough
to be ignored.

He already knows about IBM's current offering,Websphere PL/I
for z/OS and Windows, for just  days ago he posted
a reply from Peter Elderon of IBM.
-------------------
From: "David Frank" <dave_frank@hotmail.com> wrote in message
news:44f18726$0$20253$ec3e2dad@news.usenetmonster.com...
Newsgroups: comp.lang.pl1
Sent: Monday, August 28, 2006 6:33 PM

> You have to agree that some clarification is needed,
> I may just email Elderon asking if its NOW possible to create a
> self-contained windows exe
> that can be run on anyones Windows PC without WSED client software
> installed,   stay tuned...

Frank posted:
=========
I did inquire yesterday and got a prompt reply saying:
====
yes, of course

- Peter

"David Frank" <dave_frank@hotmail.com> wrote on 08/27/2006 05:11:18 AM:

> Hi Peter,
> Can Websphere PL/I create a EXE such that it can be executed on anyone's
> Windows
> machine without any kind of Websphere support client first being
> installed?


0
robin_v (2737)
9/4/2006 1:28:40 AM
"David Frank" <dave_frank@hotmail.com> wrote in message 
news:44faac99$0$20236$ec3e2dad@news.usenetmonster.com...
>
> Other than OOP features,  how about listing the 5 most important  features it 
> lacks
> (in your opinion)..
>
> 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
> 2. for a  O.S.  thats being sold
> 3. for a computer thats being sold
> 4. PRICE < $3000
>
> I think those are reasons enuf to ignore PL/I
>
PL/I cannot be ignored so easily.  It was one of the earliest
languages to introduce some of the most important features
now standard in most modern programming languages.  Sebesta
disparages some of those features, but makes the point that,
at the time PL/I introduced those features, it was a pioneering
effort and no one had prior experience with them.  Several other
authors of comparative programming textbooks seem to have
written PL/I off as unworthy of extended comment.  If for no
other reason than its historical contribution, it does deserve some
notice in any class on comparative programming languages.

I have found, in my own research, that there is still a dedicated
group of PL/I users doing great work with the language.  It would
not be just for me to dismiss it so easily.   From the perspective
of procedural programming, it seems to me that it is still a
better language for applications programming than the more popular
language, C.

On the other hand, I have been trying to get a handle on the evolution
of the language.  When I ask a question about that concern, the
reply is usually an ad hominen rant.  Exceptions to this are Mssrs.
Linden and Lidral, both of whom have been polite, informative,
and good sources of objective information.   I can only suggest
that, if you dislike PL/I, you simply use something  else.   Those
who do like it are probably doing just fine with it.  Why would
you want to argue with those who enjoy what they are doing.

My motives are quite different.  This is not intended as the fomenting
of a flame war.  Although I am not a fan  of PL/I, I do want to make sure
it gets a fair hearing in my classroom.   I also introduce and
encourage experimentation with other languages that are not
my personal favorites.   Further, I encourage my students to
argue in favor of their own preferences.   Many of them really
like Java.  My own opinion of Java is not that favorable.

In particular, I was hoping to find an OOP implementation of the
PL/I language.  There are some proposals for OOP in PL/I, but I
cannot locate an actual implementation.

As to your issues, mentioned above.  I think there are existing PL/I
compilers still being sold.   And those seem to be targeted to computers
that are still being used for real problems.  It is premature to write-off
the mainframe computer.   As to price, one might reply with a glib,"It
costs a little more for the very best."    The fact is that, for a mainframe
compiler, $3000 does not seem like a lot of money.   On the other hand,
if you mean $3000 per seat (per programmer), that is a bit steep for
some organizations.  As noted earlier, if you find PL/I so intolerable,
it is probably in your own best interest to look for an alternative that
is better suited to your style of programming.

Richard Riehle







0
adaworks2 (748)
9/4/2006 1:43:44 AM
<adaworks@sbcglobal.net> wrote in message 
news:kxLKg.1055$MF1.374@newssvr25.news.prodigy.net...
>
> "David Frank" <dave_frank@hotmail.com> wrote in message 
> news:44faac99$0$20236$ec3e2dad@news.usenetmonster.com...
>>
>> Other than OOP features,  how about listing the 5 most important 
>> features it lacks
>> (in your opinion)..
>>

You brought the subject up but when I asked for lacking features in reply,
you dont respond.

>> 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
>> 2. for a  O.S.  thats being sold
>> 3. for a computer thats being sold
>> 4. PRICE < $3000
>>
>> I think those are reasons enuf to ignore PL/I
>>
> PL/I cannot be ignored so easily.

If its not available for the combined criteria above,  its EASILY ignored..
(ask your students)
e.g.  AFAIK the only windows compilers available  IBM > $3000  Liant > 
$10000

Your main-frame defense for PL/I is understandable since how many ADA
compilers are there for Windows < $3000   ( zero would be my guess)



0
dave_frank (2243)
9/4/2006 7:58:33 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:cjLKg.22641$rP1.15366@news-server.bigpond.net.au...
> "David Frank" <dave_frank@hotmail.com> wrote in message
> news:44faac99$0$20236$ec3e2dad@news.usenetmonster.com...
>>
>> 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
>
> It is.
>
>> 2. for a  O.S.  thats being sold
>
> it is. (Frank thinks that Widows is not sold any more)
>
>> 3. for a computer thats being sold
>
> It is. (Frank thinks that Intel machines are not being sold any more)
>
>> 4. PRICE < $3000
>
> Try free.
>

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.

"Oh what a tangled web we weave when first we practice to deceive"  -- Sir 
Walter Scott



0
dave_frank (2243)
9/4/2006 8:17:03 AM
adaworks@sbcglobal.net wrote:

> 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.
it does, it does :-)

> 
> When compared to most other contemporary languages I
> still find it lacking -- especially in OOP features.
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.

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

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/


> 
> I would be happy to include it in my discussion of OOP languages
> if there is an real implementation out there somewhere.

Have you had a look at the latest version of the IBM Enterprise compiler,
here some new features that makes encapsulation easier, are implemented ?

> 
> Richard Riehle
Henrik Sorensen

pl1gcc.sourceforge.net
0
9/4/2006 11:22:51 AM
adaworks@sbcglobal.net wrote:
> As noted earlier, if you find PL/I so intolerable,
> it is probably in your own best interest to look for an alternative that
> is better suited to your style of programming.
> 
Maybe one that  introduces random errors into compiled code ;-)

0
Peter_Flass (956)
9/4/2006 11:38:33 AM
henrik.sorensen@balcab.ch 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).
 
http://books.google.com/books?vid=ISBN1558604960&id=h34d_jr2iikC&pg=PA1&lpg=PA1&dq=%22linkers+and+loaders%22&sig=KUrIeTY_eZmGJHw3aU_I0k_TPMk

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.

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.

0
Peter_Flass (956)
9/4/2006 11:47:37 AM
On Mon, 04 Sep 2006 01:17:03 -0700, David Frank <dave_frank@hotmail.com>  
wrote:

>
> "robin" <robin_v@bigpond.com> wrote in message
> news:cjLKg.22641$rP1.15366@news-server.bigpond.net.au...
>> "David Frank" <dave_frank@hotmail.com> wrote in message
>> news:44faac99$0$20236$ec3e2dad@news.usenetmonster.com...
>>>
>>> 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
>>
>> It is.
>>
>>> 2. for a  O.S.  thats being sold
>>
>> it is. (Frank thinks that Widows is not sold any more)
>>
>>> 3. for a computer thats being sold
>>
>> It is. (Frank thinks that Intel machines are not being sold any more)
>>
>>> 4. PRICE < $3000
>>
>> Try free.
>>
>
> 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.
>
> "Oh what a tangled web we weave when first we practice to deceive"  --  
> Sir
> Walter Scott
>
Wasn't that from Midsummernight's Dream ?
>
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/4/2006 12:20:28 PM
Peter Flass wrote:

> henrik.sorensen@balcab.ch 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).

using standard PL/I in a disciplined manner it is possible to some OOP style
programming, but it is in most cases something you will have to program
yourself. This is not necessary a bad idea, it just require strict coding
rules.

One example.

In Java you can do this, sorry for any syntax errors:

public class A
{
  public A // constructor
  { doit();
  }

  protected void doit
  { System.out.println("default action, not overwritten by any classes");
  }
}

public class B extend A
{ 
  public B // constructor
  { super(); 
  }
  protected void doit  // Override method in A
  { System.out.println("this doit is better for B");
  }
}


the purpose of the above example, when the constructor of B is invoked,
invoke the extend constructor A, and within A constructor, the method doit
form B will be invoked.

I am not saying this is a particular elegant way of using inheritance. But
this is what I mean by only supporting 'interfaces'. The creator of class A
should have provided an interface for this class instead of relying on the
inheritance mechanism. One problem with the inheritance mechanism like this
one outlined here, is program very easily becomes extremely difficult to
follow.


>  
>
http://books.google.com/books?vid=ISBN1558604960&id=h34d_jr2iikC&pg=PA1&lpg=PA1&dq=%22linkers+and+loaders%22&sig=KUrIeTY_eZmGJHw3aU_I0k_TPMk
> 
> 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.
sound interesting I will have a closer look at the features in Multics, once
real code generation starts.

> 
> 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.
hey feel free to join the open source movement ... :-)

Henrik
0
9/4/2006 2:15:55 PM
"David Frank" <dave_frank@hotmail.com> wrote in message
news:44fbe03e$0$12071$ec3e2dad@news.usenetmonster.com...
>
> "robin" <robin_v@bigpond.com> wrote in message
> news:cjLKg.22641$rP1.15366@news-server.bigpond.net.au...
> > "David Frank" <dave_frank@hotmail.com> wrote in message
> > news:44faac99$0$20236$ec3e2dad@news.usenetmonster.com...
> >>
> >> 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
> >
> > It is.
> >
> >> 2. for a  O.S.  thats being sold
> >
> > it is. (Frank thinks that Widows is not sold any more)
> >
> >> 3. for a computer thats being sold
> >
> > It is. (Frank thinks that Intel machines are not being sold any more)
> >
> >> 4. PRICE < $3000
> >
> > Try free.
>
> 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.

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.


0
robin_v (2737)
9/4/2006 3:10:04 PM
"David Frank" <dave_frank@hotmail.com> wrote in message 
news:44fbdbe8$0$12080$ec3e2dad@news.usenetmonster.com...
>
> Your main-frame defense for PL/I is understandable since how many ADA
> compilers are there for Windows < $3000   ( zero would be my guess)
>
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



0
adaworks2 (748)
9/4/2006 4:50:13 PM
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...
> adaworks@sbcglobal.net wrote:
>
>> 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.
> it does, it does :-)
>
>>
>> When compared to most other contemporary languages I
>> still find it lacking -- especially in OOP features.
> 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.
>
>>
>> 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.
>
> 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/
>
>
>>
>> I would be happy to include it in my discussion of OOP languages
>> if there is an real implementation out there somewhere.
>
> Have you had a look at the latest version of the IBM Enterprise compiler,
> here some new features that makes encapsulation easier, are implemented ?
>
>>
>> Richard Riehle
> Henrik Sorensen
>
> pl1gcc.sourceforge.net 


0
adaworks2 (748)
9/4/2006 4:56:01 PM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
news:tnUKg.33727$8j3.4895@twister.nyroc.rr.com...
>
> 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).
>
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 


0
adaworks2 (748)
9/4/2006 4:59:50 PM
Peter Flass wrote:
> henrik.sorensen@balcab.ch 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).
> 
> http://books.google.com/books?vid=ISBN1558604960&id=h34d_jr2iikC&pg=PA1&lpg=PA1&dq=%22linkers+and+loaders%22&sig=KUrIeTY_eZmGJHw3aU_I0k_TPMk 
> 
> 
> 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.
> 
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.

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

Bob Lidral
lidral  at  alum  dot  mit  dot  edu
0
9/4/2006 6:33:05 PM
adaworks@sbcglobal.net wrote:
> 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.
> 

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.

0
Peter_Flass (956)
9/4/2006 7:45:22 PM
Bob Lidral wrote:

> Peter Flass wrote:
> 
>> henrik.sorensen@balcab.ch 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).
>>
>> http://books.google.com/books?vid=ISBN1558604960&id=h34d_jr2iikC&pg=PA1&lpg=PA1&dq=%22linkers+and+loaders%22&sig=KUrIeTY_eZmGJHw3aU_I0k_TPMk 
>>
>>
>> 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.
>>
> 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.

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.

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

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.

0
Peter_Flass (956)
9/4/2006 8:01:55 PM
adaworks@sbcglobal.net wrote:

> Henrik,
> 
> Excellent reply.  I will take a look at the OO extensions.
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.

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


o:proc(name);
   open file(....);
end o;

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

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

initMyInterface:proc;
  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.


> 
> 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.
look into the GENERIC declares, and into the RETURNS option of the procedure
statement.


> Richard Riehle
Henrik 
0
9/4/2006 8:17:24 PM

Peter Flass wrote:
> Bob Lidral wrote:
> 
>> Peter Flass wrote:
>>
>>> henrik.sorensen@balcab.ch 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).
>>>
>>> http://books.google.com/books?vid=ISBN1558604960&id=h34d_jr2iikC&pg=PA1&lpg=PA1&dq=%22linkers+and+loaders%22&sig=KUrIeTY_eZmGJHw3aU_I0k_TPMk 
>>>
>>>
>>> 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.
>>>
>> 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.
> 
> 
> 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.
> 
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.)
>>
>> 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.
> 
> 
> 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.
> 
0
donaldldobbs (108)
9/4/2006 10:10:39 PM
adaworks@sbcglobal.net wrote:

> However, I am not happy that Java has no simple way to include
> functions (methods) as parameters to other methods.
I have seen it done via passing classes implementing the required interface
for the method.

Henrik
0
9/4/2006 10:15:34 PM
adaworks@sbcglobal.net wrote:

> C++ is one of the ugliest languages ever invented. 

Except for all the others.

Beauty, even in programming languages is in the eye (ouch) of the beholder.

Unless you can put a number to this, its just an opinion.

Mine differs from yours, we probably both differ from the opinions that 
DF and Robin hold.

LR
0
lruss (582)
9/5/2006 1:51:04 AM
Peter Flass wrote:

> henrik.sorensen@balcab.ch wrote:
> 

> I don't know much about OOP, though I'd like to learn more.  

If I understood his post elsewhere in this thread correctly, Henrik 
Sorensen is right, OOP can be done in almost any language, PL/I 
included.  The PL/I pre-processor may be useful if you want to do PL/I OOP.

But if you're just learning, then there are plenty of languages which 
have better, although not perfect, support for OOP features.  Many of 
these languages have freeish implementations that are downloadable. At 
least for various PC environments.

In particular, I suggest one of the following:

First, not withstanding what you wrote:
 > 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).

(I freely admit I have trouble understanding the above. I don't think 
that name mangling has anything to do with anything that is GENERIC in 
PL/I.  And this also, I suspect has little to do with 'template's in C++.)

Just in case you were unaware, I think C++ is a really nice language. 
There are several free versions available.  I think that MS has a free 
express version you can use with an IDE.

Secondly, Java.  Lots of people think it's just great.  I think you can 
still download a compiler from Sun. If you're not worried about pure 
Java, there are other sources.  MS might have an express version of J# 
with an IDE for free, but I'm not sure.

Thirdly PERL.  Now has some OOP features.  As I recall it has nice 
support for double dispatch 
(http://en.wikipedia.org/wiki/Double_dispatch)  Not my favorite 
language, but available in lots of environments, AFAIR.

I'm sure DF will tell you that Fortran has OOP added to the last 
standard, even if no compilers implement it yet, I think.

And of course lots of others.



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

Sounds like fun.  You may want to visit www.accu.org to look for book 
reviews that might be of interest.

Good luck.

LR


0
lruss (582)
9/5/2006 2:25:46 AM
Tom Linden wrote:
> On Mon, 04 Sep 2006 01:17:03 -0700, David Frank 
> <dave_frank@hotmail.com>  wrote:
> 
>>
>> "robin" <robin_v@bigpond.com> wrote in message
>> news:cjLKg.22641$rP1.15366@news-server.bigpond.net.au...
>>
>>> "David Frank" <dave_frank@hotmail.com> wrote in message
>>> news:44faac99$0$20236$ec3e2dad@news.usenetmonster.com...
>>>
>>>>
>>>> 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
>>>
>>>
>>> It is.
>>>
>>>> 2. for a  O.S.  thats being sold
>>>
>>>
>>> it is. (Frank thinks that Widows is not sold any more)
>>>
>>>> 3. for a computer thats being sold
>>>
>>>
>>> It is. (Frank thinks that Intel machines are not being sold any more)
>>>
>>>> 4. PRICE < $3000
>>>
>>>
>>> Try free.
>>>
>>
>> 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.
>>
>> "Oh what a tangled web we weave when first we practice to deceive"  
>> --  Sir
>> Walter Scott
>>
> Wasn't that from Midsummernight's Dream ?
> 

No, it's from Marmion.  DF doesn't know much about PL/I but he seems to know his 
literature, at least in this instance.

0
jjw (608)
9/5/2006 3:36:59 AM
"LR" <lruss@superlink.net> wrote in message 
news:44fcd7f6$0$6829$cc2e38e6@news.uslec.net...
> adaworks@sbcglobal.net wrote:
>
>> C++ is one of the ugliest languages ever invented.
>
> Except for all the others.
>
> Beauty, even in programming languages is in the eye (ouch) of the beholder.
>
> Unless you can put a number to this, its just an opinion.
>
I am not sure I have the numerical data to support my view.  However, when
one looks closely at the C++ language and sees how it requires all sorts of
workarounds to get things done, particularly with regard to pointers, it looks
pretty bad to me.

An object-oriented programming language such as Eiffel provides a consistent,
orthogonal approach to software development that is much more elegant than
C++.   Admittedly, Eiffel did not have to depend on the the requirement to
build an OO language on top of something as hideous as C.  The designer
of Eiffel had the freedom to create a language that was well-designed from
the ground up.

> Mine differs from yours, we probably both differ from the opinions that DF and 
> Robin hold.
>
I have used C++ on projects, taught C++ in industry, and taught C++ in
the academic environment.   The more time I spend with the language, the
more I dislike it.   So much of what one has to do to create a large-scale
program that works correctly seems to involve workarounds that are not
present in other languages: friend functions,  cryptic notations, and a model 
for
multiple inheritance that is fraught with danger.   The C++ textbooks
are full of warnings about some features that need to be used with care,
or not used at all.

So, when I say I think it is ugly, I guess it is true that my esthetic sense
is in the "eye of the beholder."   If I never had to write another C++
program again, I would be just as happy.   Unfortunately, the language
has caught hold of the programming community.   It is the peanut-brittle
of programming languages.  At first it tastes sweet, but then one finds
it is crunchy.   Finally, just as peanut brittle rots one's teeth, C++ rots
away even the best of programs.

Richard Riehle 


0
adaworks2 (748)
9/5/2006 5:29:08 AM
adaworks@sbcglobal.net wrote:

(snip)

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

I thought Java could do it, but maybe not simple enough for you.

PL/I has ENTRY variables which can do that, a little more
general than Fortran had before 2003.

-- glen

0
gah (12851)
9/5/2006 5:29:37 AM
<henrik.sorensen@balcab.ch> wrote in message 
news:30cec$44fc8931$5448c618$11732@news.hispeed.ch...
> adaworks@sbcglobal.net wrote:
>
>> However, I am not happy that Java has no simple way to include
>> functions (methods) as parameters to other methods.
> I have seen it done via passing classes implementing the required interface
> for the method.
>
Yes, this works.  However, it is a bit of a kludge.  Most languages (C++, C,
even Ada) require a pointer to accomplish this.  In C++ this requires a
pointer to a function.   Ada is a little better since it has a safer model of
pointers.  The C# approach is rather nice.  It uses a special kind of function
called a delegate.   I also like the approach taken by Python, although this
language, like C or C++, is not a good option when one demands a high
level of dependability from the deployed program.

If Java supported some kind of indirection (not C++ pointers), this could
be implemented.  In fact, there is no reason why functions could not be
designed over a reference model in Java.   The Java language is so full if
promise and falls short of what it could have been had it not been rushed
to market.   Well, at least it now has genericity.

Richard 


0
adaworks2 (748)
9/5/2006 5:38:00 AM
"LR" <lruss@superlink.net> wrote in message 
news:44fce01a$0$6837$cc2e38e6@news.uslec.net...
> Peter Flass wrote:
>
>> henrik.sorensen@balcab.ch wrote:
>>
>
>> I don't know much about OOP, though I'd like to learn more.
>
> If I understood his post elsewhere in this thread correctly, Henrik Sorensen 
> is right, OOP can be done in almost any language, PL/I included.  The PL/I 
> pre-processor may be useful if you want to do PL/I OOP.
>
I someone is starting to learn object-oriented programming for the first time,
Eiffel is my number one recommendation.   It has not legacy to C or C++.
It does not have all the silly conventions that are usually carried over from
C.

Eiffel is a language designed specifically to support the object-oriented
programming paradigm.  It is simple to learn once you get past the fact
that it looks different from any other language you have ever seen.

The Eiffel language supports, not only the object-oriented programming
approach in a direct and uncomplicated way, it also includes a powerful
capability called Design by Contract, something that is absent from any
of the other languages so far mentioned in this discussion.

You can download an Eiffel compiler for free.  You can also visit,
             www.eiffel.com

C++ is not a good place to start learning object-oriented programming.
The language design is far too complicated for that.

Richard Riehle 


0
adaworks2 (748)
9/5/2006 5:46:19 AM
Bob Lidral <l1dralspamba1t@comcast.net> wrote:
(snip)
 
> 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.

This is sort of, but not completely true.  First, language standards
don't separate compiler, linker, and OS.  But also many features
of OS and linkers are designed around the needs of languages (compilers).

One result, though, is that each new language has to run on systems
designed around older languages.  The OS/360 linker had some features
added to support PL/I, such as pseudo-registers, but otherwise it
mostly has features needed for Fortran.  (The eight character limit
for external names is a little more than six for Fortran, but less
than it should have had for PL/I.)

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

If the linker had been developed to support such generic procedures it
would have been included.  

-- glen
0
gah1 (524)
9/5/2006 5:38:30 PM
adaworks@sbcglobal.net wrote:
> "LR" <lruss@superlink.net> wrote in message 
> news:44fcd7f6$0$6829$cc2e38e6@news.uslec.net...
> 
>>adaworks@sbcglobal.net wrote:
>>
>>
>>>C++ is one of the ugliest languages ever invented.
>>
>>Except for all the others.
>>
>>Beauty, even in programming languages is in the eye (ouch) of the beholder.
>>
>>Unless you can put a number to this, its just an opinion.
>>
> 
> I am not sure I have the numerical data to support my view.  

Please let me know when you can do this.  ;)

 > However, when
> one looks closely at the C++ language and sees how it requires all sorts of
> workarounds to get things done, particularly with regard to pointers, it looks
> pretty bad to me.

Then don't use pointers. At least not directly.  Use references, and 
make use of the std library.  I don't think that I've directly used a 
raw pointer in C++ in about ten years.  And I have access to some nice 
things, like arrays that can grow at will, if thats what I want, and 
std::map.

And the nice thing about C++, from another perspective, is that the 
language doesn't limit you.  If you want to do something that might not 
have been anticipated by the language designers, very often you can. For 
example, see www.boost.org.

(And no, by that last sentence, I didn't mean that some languages can't 
complete some task that some other language can.  There really aren't 
many CAN'Ts, just libraries that haven't been implemented with a binding 
for a particular language.)



> An object-oriented programming language such as Eiffel provides a consistent,
> orthogonal approach to software development that is much more elegant than
> C++.   Admittedly, Eiffel did not have to depend on the the requirement to
> build an OO language on top of something as hideous as C.  The designer
> of Eiffel had the freedom to create a language that was well-designed from
> the ground up.

Oh sure, I'll grant that C++ is not a perfect language.  And if you 
think that Eiffel is the language for you, then by all means, use it.

Yes, from what I've heard, Eiffel is "elegant" and "well-designed" and 
may even have a purer object model than C++.  But sorry, in the real 
world, VHS won over Beta,  the PC has for the most part won over the 
Mac.  Some people think that the Jeep helped win WWII. IMHO, even valid 
arguments about technological superiority almost always lose to utility.


>>Mine differs from yours, we probably both differ from the opinions that DF and 
>>Robin hold.
>>
> 
> I have used C++ on projects, taught C++ in industry, and taught C++ in
> the academic environment.   The more time I spend with the language, the
> more I dislike it.

Whereas my experience has been the exact opposite.



 > So much of what one has to do to create a large-scale
> program that works correctly seems to involve workarounds that are not
> present in other languages: friend functions,  cryptic notations, and a model 
> for
> multiple inheritance that is fraught with danger. 


We are perhaps moving off topic for this group, but I'm not certain why 
you _have_ to use friend functions, I'm not sure that there is ever a 
requirement for that.  Cryptic notations?  I'm sure that every language 
has these, and I agree that C and C++ are not perfect in this regard, 
and perhaps a little more subject to abuse.  But as I say, whatever 
language you write in can be abused, and there is no requirement that 
you abuse it.  Multiple inheritance has some gotchas, like many things 
it may be wise to use it sparingly, but it is available in the language 
if you _must_ use it.



 > The C++ textbooks
> are full of warnings about some features that need to be used with care,
> or not used at all.

Yes. Well, if you have real tools, then you have real worries.  My 
advice is that if you ever operate a lathe you wear safety glasses and a 
shop apron and no tie.


> 
> So, when I say I think it is ugly, I guess it is true that my esthetic sense
> is in the "eye of the beholder."  

I don't think that you've established that it's ugly, just that you 
don't like its features.  Two quite different things.  But let's assume 
for the moment that we can conflate these.

 > If I never had to write another C++
> program again, I would be just as happy.   Unfortunately, the language
> has caught hold of the programming community.   

Yes.  It sure has. :-) And for good reason. Although, I can't put a 
number to that either.

 >It is the peanut-brittle
> of programming languages.  At first it tastes sweet, but then one finds
> it is crunchy.   Finally, just as peanut brittle rots one's teeth, C++ rots
> away even the best of programs.

Not in my experience.  In my experience, if you code reasonably well, 
then C++ can be your friend. Easy to use, easy to maintain and add new 
features. Just because something is easy to use doesn't mean that it 
can't be abused, but just as I make an effort not to drive my car into 
walls, I make a similar effort not to abuse C++.  And make no mistake 
about it, there are two kinds of programming languages:  Those that can 
be abused, and those that it is difficult to get work done in.  Of 
course, where each of us might draw the line between usability and 
safety might differ, so YMMV.

BTW, I think that we may have moved OT for this group, if you want to 
continue this, then maybe we'd be better off with email?  But I'll leave 
that up to you.

LR
0
lruss (582)
9/5/2006 6:14:40 PM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
news:mn%Kg.36257$uH6.32191@twister.nyroc.rr.com...
> adaworks@sbcglobal.net wrote:

Yet another question, in an attempt to clarify some
points.

In all the documentation I and programming examples I
have been examining, it seems the IF statement is not
accompnied by a corresponding END.  It is possible
to put a DO ... END bracket around it but does not
seem to be required by the compiler.

I am sure that modern PL/I has probably corrected this
potential for "dangling if" statements, but I cannot find the
citation for it.   Fortran and COBOL corrected this
a long time ago.  I am sure that, by now, PL/I has
also corrected it.

Any thoughts.

Richard Riehle 


0
adaworks2 (748)
9/6/2006 4:14:38 AM

adaworks@sbcglobal.net wrote:
> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
> news:mn%Kg.36257$uH6.32191@twister.nyroc.rr.com...
> 
>>adaworks@sbcglobal.net wrote:
> 
> 
> Yet another question, in an attempt to clarify some
> points.
> 
> In all the documentation I and programming examples I
> have been examining, it seems the IF statement is not
> accompnied by a corresponding END.  It is possible
> to put a DO ... END bracket around it but does not
> seem to be required by the compiler.
> 
> I am sure that modern PL/I has probably corrected this
> potential for "dangling if" statements, but I cannot find the
> citation for it.   Fortran and COBOL corrected this
> a long time ago.  I am sure that, by now, PL/I has
> also corrected it.
> 

IF CONDITION THEN stmt-1;	/* only one stmt for the condition */

IF CONDITION THEN
	DO;
	stmt-1;
	stmt-2;
	...
	stmt-n;
	END;

IF CONDITION THEN DO; stmt-1; END;   /* acceptable but not necessary */

> Any thoughts.
> 
> Richard Riehle 
> 
> 
0
donaldldobbs (108)
9/6/2006 5:22:34 AM
adaworks@sbcglobal.net wrote:
> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
> news:mn%Kg.36257$uH6.32191@twister.nyroc.rr.com...
> 
>>adaworks@sbcglobal.net wrote:
> 
> 
> Yet another question, in an attempt to clarify some
> points.
> 
> In all the documentation I and programming examples I
> have been examining, it seems the IF statement is not
> accompnied by a corresponding END.  It is possible
> to put a DO ... END bracket around it but does not
> seem to be required by the compiler.
> 
> I am sure that modern PL/I has probably corrected this
> potential for "dangling if" statements, but I cannot find the
> citation for it.   Fortran and COBOL corrected this
> a long time ago.  I am sure that, by now, PL/I has
> also corrected it.

No.  Why is this a problem?

0
Peter_Flass (956)
9/6/2006 10:17:27 AM
Peter Flass wrote:
> adaworks@sbcglobal.net wrote:
> > "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
> > news:mn%Kg.36257$uH6.32191@twister.nyroc.rr.com...
> >
> >>adaworks@sbcglobal.net wrote:
> >
> >
> > Yet another question, in an attempt to clarify some
> > points.
> >
> > In all the documentation I and programming examples I
> > have been examining, it seems the IF statement is not
> > accompnied by a corresponding END.  It is possible
> > to put a DO ... END bracket around it but does not
> > seem to be required by the compiler.
> >
> > I am sure that modern PL/I has probably corrected this
> > potential for "dangling if" statements, but I cannot find the
> > citation for it.   Fortran and COBOL corrected this
> > a long time ago.  I am sure that, by now, PL/I has
> > also corrected it.
>
> No.  Why is this a problem?

It is not a problem if the grammar for the language unambigously
specifies how the following is interpreted:

IF cond1 THEN stmt1; IF cond2 THEN stmt2; ELSE stmt3;

As long as the user (and the compiler) knows if the ELSE statement
belongs to the first or the second IF, then there is no problem. Many
languages do require a block construct in such cases, just to make it
extra clear how this works, but that's just syntactic sugar.

And, by the way, I don't know how this is interpreted by PL/1, but I
assume the ELSE associates with the last (closest) IF, right?

-- 
Sven Axelsson

0
9/6/2006 12:32:29 PM
Following up to "sven.axelsson@gmail.com" <sven.axelsson@gmail.com> :

>And, by the way, I don't know how this is interpreted by PL/1, but I
>assume the ELSE associates with the last (closest) IF, right?


Correct: 

IF cond1 
THEN stmt1;

IF cond2 
THEN stmt2; 
ELSE stmt3;


to make it refer to the first IF you'd have to write:

IF cond1 
THEN DO;
     stmt1;

     IF cond2 
     THEN stmt2; 
END;
ELSE stmt3;
-- 
Tim C.
0
9/6/2006 12:52:42 PM
On Wed, 06 Sep 2006 05:32:29 -0700, sven.axelsson@gmail.com  
<sven.axelsson@gmail.com> wrote:

> Peter Flass wrote:
>> adaworks@sbcglobal.net wrote:
>> > "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
>> > news:mn%Kg.36257$uH6.32191@twister.nyroc.rr.com...
>> >
>> >>adaworks@sbcglobal.net wrote:
>> >
>> >
>> > Yet another question, in an attempt to clarify some
>> > points.
>> >
>> > In all the documentation I and programming examples I
>> > have been examining, it seems the IF statement is not
>> > accompnied by a corresponding END.  It is possible
>> > to put a DO ... END bracket around it but does not
>> > seem to be required by the compiler.
>> >
>> > I am sure that modern PL/I has probably corrected this
>> > potential for "dangling if" statements, but I cannot find the
>> > citation for it.   Fortran and COBOL corrected this
>> > a long time ago.  I am sure that, by now, PL/I has
>> > also corrected it.
>>
>> No.  Why is this a problem?
>
> It is not a problem if the grammar for the language unambigously
> specifies how the following is interpreted:
>
> IF cond1 THEN stmt1; IF cond2 THEN stmt2; ELSE stmt3;
>
> As long as the user (and the compiler) knows if the ELSE statement
> belongs to the first or the second IF, then there is no problem. Many
> languages do require a block construct in such cases, just to make it
> extra clear how this works, but that's just syntactic sugar.
>
> And, by the way, I don't know how this is interpreted by PL/1, but I
> assume the ELSE associates with the last (closest) IF, right?
>
Yes, they are nested and it is a bit involved.  A less capable parser would
need an endif to terminate the processing, but there is a good reason PL/I
is implemented as a recursive descent parser.  The general form of the  
statement

IF <|expression|> THEN <|executable-unit|> | <|balanced-unit|> ELSE  
<|executable-unit|>

and the involved entities contain recursive definitions.  Balancing DO or  
BEGIN
with corresponding END statements is always a nuisance for beginning  
programmers
and is mitigated by using the nesting option on the list file or, as I  
prefer, using
a syntax sensitive editor like emacs.





-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/6/2006 12:56:09 PM
sven.axelsson@gmail.com wrote:
> It is not a problem if the grammar for the language unambigously
> specifies how the following is interpreted:
>
> IF cond1 THEN stmt1; IF cond2 THEN stmt2; ELSE stmt3;

Oops, typed too fast. The ambiguity occurs in this case:

IF cond1 THEN; IF cond2 THEN stmt2; ELSE stmt3;

not as previously stated. But you all knew that already...

-- 
Sven Axelsson

0
9/6/2006 2:41:11 PM
On Wed, 06 Sep 2006 07:41:11 -0700, sven.axelsson@gmail.com  
<sven.axelsson@gmail.com> wrote:

>
> sven.axelsson@gmail.com wrote:
>> It is not a problem if the grammar for the language unambigously
>> specifies how the following is interpreted:
>>
>> IF cond1 THEN stmt1; IF cond2 THEN stmt2; ELSE stmt3;
>
> Oops, typed too fast. The ambiguity occurs in this case:
>
> IF cond1 THEN; IF cond2 THEN stmt2; ELSE stmt3;
>
> not as previously stated. But you all knew that already...
>

No, there is no ambiguity  IF cond1 THEN;   is a no op because the
executable unit is a null statement.


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/6/2006 2:49:58 PM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
news:XexLg.34065$8j3.14230@twister.nyroc.rr.com...
> adaworks@sbcglobal.net wrote:
>>
>> I am sure that modern PL/I has probably corrected this
>> potential for "dangling if" statements, but I cannot find the
>> citation for it.   Fortran and COBOL corrected this
>> a long time ago.  I am sure that, by now, PL/I has
>> also corrected it.
>
> No.  Why is this a problem?
>
It is potentially a problem for the same reason it
was a problem with Fortran and COBOL.  The
reason most PL/I programs I have been reading
use the DO ... END delimiters seems to be to
eliminate the problem.   This avoids the
inherent ambiguity in the absence of an END for
each IF.

Even though the parser may interpret it correctly,
and that seems to be an outstanding question, the
reader of the program may not.   Further, the original
coder can certainly make a mistake with this quite
easily, especially in the case of nested IF statements,
where I have been observing this during my research.

This problem exists in C and is carried over to C++
and others in the C family of languages.   That is
why careful programmers use curly-braces to prevent
ambiguity.  Pascal programmers must also use a
DO... END to avoid ambiguity approach since it
also has the dangling if issue.

Many newer languages have eliminated the need for
a DO ... END kind of delimiter by simply requiring
an END for every IF.   That, in turn has forced those
languages to add another construct, ELSEIF or
ELSIF, or something like it, to distinguish between
the original IF and a subordinate IF.  They use this
for multi-way selection (as opposed to the simple
alternation style selection of a standard IF).  In fact,
a few languages have eliminated the "case" (PL/I
SELECT) statement entirely in favor of the ELSIF
option.

So, it appears that in PL/I, as in C and Pascal, the
DO...END brackets are required to avoid ambiguity.
No problem. I just wanted to clear this up in my
own mind.

Richard Riehle 


0
adaworks2 (748)
9/6/2006 3:39:13 PM
Tom Linden wrote:
> On Wed, 06 Sep 2006 07:41:11 -0700, sven.axelsson@gmail.com
> <sven.axelsson@gmail.com> wrote:
>
> >
> > sven.axelsson@gmail.com wrote:
> >> It is not a problem if the grammar for the language unambigously
> >> specifies how the following is interpreted:
> >>
> >> IF cond1 THEN stmt1; IF cond2 THEN stmt2; ELSE stmt3;
> >
> > Oops, typed too fast. The ambiguity occurs in this case:
> >
> > IF cond1 THEN; IF cond2 THEN stmt2; ELSE stmt3;
> >
> > not as previously stated. But you all knew that already...
> >
>
> No, there is no ambiguity  IF cond1 THEN;   is a no op because the
> executable unit is a null statement.

Yeah, well that was another slip of the finger. Serves me right for
trying to use PL/1 syntax.

IF cond1 THEN IF cond2 THEN stmt1; ELSE stmt2;

or written more obscurely:

IF cond1 THEN
    IF cond2 THEN 
        stmt2; 
ELSE 
    stmt3;

-- 
Sven Axelsson

0
9/6/2006 3:41:41 PM
On Wed, 06 Sep 2006 08:41:41 -0700, sven.axelsson@gmail.com  
<sven.axelsson@gmail.com> wrote:

>
> Tom Linden wrote:
>> On Wed, 06 Sep 2006 07:41:11 -0700, sven.axelsson@gmail.com
>> <sven.axelsson@gmail.com> wrote:
>>
>> >
>> > sven.axelsson@gmail.com wrote:
>> >> It is not a problem if the grammar for the language unambigously
>> >> specifies how the following is interpreted:
>> >>
>> >> IF cond1 THEN stmt1; IF cond2 THEN stmt2; ELSE stmt3;
>> >
>> > Oops, typed too fast. The ambiguity occurs in this case:
>> >
>> > IF cond1 THEN; IF cond2 THEN stmt2; ELSE stmt3;
>> >
>> > not as previously stated. But you all knew that already...
>> >
>>
>> No, there is no ambiguity  IF cond1 THEN;   is a no op because the
>> executable unit is a null statement.
>
> Yeah, well that was another slip of the finger. Serves me right for
> trying to use PL/1 syntax.
>
> IF cond1 THEN IF cond2 THEN stmt1; ELSE stmt2;
>
> or written more obscurely:
>
> IF cond1 THEN
>     IF cond2 THEN
>         stmt2;
> ELSE
>     stmt3;
>
Still no problem.  To make it clear let me rewrite what you wrote
using indentation to indicate nesting levels

IF cond1 THEN
    IF cond2 THEN
       stmt2;
    ELSE
       stmt3;

Not sure why you think there is an ambiguity here.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/6/2006 3:56:03 PM
On Wed, 06 Sep 2006 08:39:13 -0700, <adaworks@sbcglobal.net> wrote:

>
> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
> news:XexLg.34065$8j3.14230@twister.nyroc.rr.com...
>> adaworks@sbcglobal.net wrote:
>>>
>>> I am sure that modern PL/I has probably corrected this
>>> potential for "dangling if" statements, but I cannot find the
>>> citation for it.   Fortran and COBOL corrected this
>>> a long time ago.  I am sure that, by now, PL/I has
>>> also corrected it.
>>
>> No.  Why is this a problem?
>>
> It is potentially a problem for the same reason it
> was a problem with Fortran and COBOL.  The
> reason most PL/I programs I have been reading
> use the DO ... END delimiters seems to be to
> eliminate the problem.   This avoids the
> inherent ambiguity in the absence of an END for
> each IF.

Richard, see my other post on this.  The DO -- END has nothing to
do with the ENDIF construction which you are alluding, which is
really sugar for a weak parser.  There really is no dangling IF
issue in PL/I, you may have unbalance DO|BEGIN END groups, just
as with braces in C

>
> Even though the parser may interpret it correctly,
> and that seems to be an outstanding question, the
> reader of the program may not.   Further, the original
> coder can certainly make a mistake with this quite
> easily, especially in the case of nested IF statements,
> where I have been observing this during my research.
>
> This problem exists in C and is carried over to C++
> and others in the C family of languages.   That is
> why careful programmers use curly-braces to prevent
> ambiguity.  Pascal programmers must also use a
> DO... END to avoid ambiguity approach since it
> also has the dangling if issue.
>
> Many newer languages have eliminated the need for
> a DO ... END kind of delimiter by simply requiring
> an END for every IF.   That, in turn has forced those
> languages to add another construct, ELSEIF or
> ELSIF, or something like it, to distinguish between
> the original IF and a subordinate IF.  They use this
> for multi-way selection (as opposed to the simple
> alternation style selection of a standard IF).  In fact,
> a few languages have eliminated the "case" (PL/I
> SELECT) statement entirely in favor of the ELSIF
> option.

More gratuitous sugar.

>
> So, it appears that in PL/I, as in C and Pascal, the
> DO...END brackets are required to avoid ambiguity.
> No problem. I just wanted to clear this up in my
> own mind.
No, there is no ambiguity, see my other post.

>
> Richard Riehle
>
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/6/2006 4:04:53 PM
Tim C. <tim.challenger@aon.at> wrote:
 
>>And, by the way, I don't know how this is interpreted by PL/1, but I
>>assume the ELSE associates with the last (closest) IF, right?
 
> Correct: 

(snip of non-ambiguous IF statements)

It gets ambiguous with something like:

IF cond1 THEN 
   IF cond2 THEN stmt1;
   ELSE stmt2;

just like in C.  Similar to C, the solution is:

IF cond1 THEN 
   IF cond2 THEN stmt1;
   ELSE ;
ELSE stmt2;

Though just like C, the ; is a statement terminator,
and so technically part of stmt1 and stmt2.  That is,
in contrast to Pascal where ; is a statement separator
and does not come before the ELSE.  That is one reason
I don't like Pascal.

There are many similarities between PL/I and C, in this
case DO; replaces {, and END; replaces }.

-- glen
 
0
gah1 (524)
9/6/2006 5:10:34 PM
adaworks@sbcglobal.net wrote:
 
> So, it appears that in PL/I, as in C and Pascal, the
> DO...END brackets are required to avoid ambiguity.
> No problem. I just wanted to clear this up in my
> own mind.

Well, the other way is that PL/I, C, and Pascal resolve
the ambiguity in the language definition, by indicating
that an ELSE goes with the most recent IF.

I don't believe that they occur often enough to be a big
problem.

-- glen
0
gah1 (524)
9/6/2006 5:15:37 PM
On Wed, 06 Sep 2006 10:10:34 -0700, glen herrmannsfeldt  
<gah@seniti.ugcs.caltech.edu> wrote:

> Tim C. <tim.challenger@aon.at> wrote:
>
>>> And, by the way, I don't know how this is interpreted by PL/1, but I
>>> assume the ELSE associates with the last (closest) IF, right?
>
>> Correct:
>
> (snip of non-ambiguous IF statements)
>
> It gets ambiguous with something like:
>
> IF cond1 THEN
>    IF cond2 THEN stmt1;
>    ELSE stmt2;
>
> just like in C.  Similar to C, the solution is:
>
> IF cond1 THEN
>    IF cond2 THEN stmt1;
>    ELSE ;
> ELSE stmt2;

If this is what was intended then I would argue that the first expression
was not ambiguous, but simply wrong.

IF ^cond1 then stmt2 else if cond2 then stmnt1; :-)

Actually our optimizer may well invert the logic in this fashion
>
> Though just like C, the ; is a statement terminator,
> and so technically part of stmt1 and stmt2.  That is,
> in contrast to Pascal where ; is a statement separator
> and does not come before the ELSE.  That is one reason
> I don't like Pascal.
>
> There are many similarities between PL/I and C, in this
> case DO; replaces {, and END; replaces }.
>
> -- glen
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/6/2006 5:16:55 PM
adaworks@sbcglobal.net wrote:

(snip)
 
> Even though the parser may interpret it correctly,
> and that seems to be an outstanding question, the
> reader of the program may not.   Further, the original
> coder can certainly make a mistake with this quite
> easily, especially in the case of nested IF statements,
> where I have been observing this during my research.

I find two kinds of IF constructs:  Those with only one
statement on each branch, and those with many.

For those with only one, I find a nice compact coding
not needing excessive END or ENDIF more readable.

People can always make mistakes, but I don't believe
that this is a big problem.

> This problem exists in C and is carried over to C++
> and others in the C family of languages.   That is
> why careful programmers use curly-braces to prevent
> ambiguity.  Pascal programmers must also use a
> DO... END to avoid ambiguity approach since it
> also has the dangling if issue.

Also, I don't find the IF/ELSEIF/ENDIF constructs
when nested and used with only one statement per branch 
to be especially readable.  

(snip)

At some point, readability is personal so I won't claim
to write for everyone, but I find some of these rules go
too far, and result in less readable programs.

-- glen 
0
gah1 (524)
9/6/2006 6:38:24 PM
adaworks@sbcglobal.net wrote:
> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
> news:XexLg.34065$8j3.14230@twister.nyroc.rr.com...
> 
>>adaworks@sbcglobal.net wrote:
>>
>>>I am sure that modern PL/I has probably corrected this
>>>potential for "dangling if" statements, but I cannot find the
>>>citation for it.   Fortran and COBOL corrected this
>>>a long time ago.  I am sure that, by now, PL/I has
>>>also corrected it.
>>
>>No.  Why is this a problem?
>>
> 
> It is potentially a problem for the same reason it
> was a problem with Fortran and COBOL.  The
> reason most PL/I programs I have been reading
> use the DO ... END delimiters seems to be to
> eliminate the problem.   This avoids the
> inherent ambiguity in the absence of an END for
> each IF.
>
There is no inherent ambiguity.

Let's be clear on our terminology. In the theory of formal languages, a grammar 
is ambiguous if there is a sentence in the language defined by that grammar that 
has more than one parse tree.  A language is ambiguous (this is the concept that 
is also called inherent ambiguity) if all grammars that define that language are 
ambiguous.

PL/I's if statement syntax in not inherently ambiguous since it is easy to write 
an unambiguous grammar for it.  Tom Linden has indicated how this can be done 
and a more detailed exposition can be found in Aho and Ullman or most other good 
texts on compiler writing.  It is after all a standard example.

That being said, it is generally preferable from a practical point of view to 
use an ambiguous grammar in conjunction with a disambiguating rule as this 
generally simplifies semantic analysis.

The way to find out how a particular construction is defined in PL/I is to 
consult a language reference manual or a published standard, not ask the 
opinions of newsgroup readers.  The LRM's for most if not all of IBM's 
implementations can be downloaded from IBM's website.

For example, here is the description of the if statement given in the LRM for 
Personal PL/I for OS/2:

The IF statement evaluates an expression and controls the flow of execution 
according to the result of that evaluation. The IF statement thus provides a 
conditional branch.

Note:  Condition prefixes are invalid on IF and ELSE statements.
┌──────────────────────────────────────────────────────────┐
│                                                                 │
│ >>──IF──expression──THEN──unit1──┬─────────────┬─────────>< │
│                                    └─ELSE──unit2─┘ 
         └──────────────────────────────────────────────────────────┘

expression:  The expression must evaluate to a bit, not a bit string, unless 
RULES(LAXIF) is used.

When expressions involve the use of the & and/or | operators, they are evaluated 
as described in Combinations of operations.

unit: Either a valid single statement, a group, or a begin-block. All single 
statements are considered valid and executable except DECLARE, DEFAULT, END, 
ENTRY FORMAT, PROCEDURE, or a %statement. If a nonexecutable statement is used, 
the result can be unpredictable. Each unit can contain statements that specify a 
transfer of control (for example, GO TO). Hence, the normal sequence of the IF 
statement can be overridden.

Each unit can be labeled and can have condition prefixes.

IF is a compound statement. The semicolon terminating the last unit also 
terminates the IF statement.

If any bit in the string expression has the value '1'B, unit1 is executed and 
unit2, if present, is ignored. If all bits are '0'B, or the string is null, 
unit1 is ignored and unit2, if present, is executed.

IF statements can be nested. That is, either unit can itself be an IF statement, 
or both can be. Since each ELSE is always associated with the innermost 
unmatched IF in the same block or do-group, an ELSE with a null statement might 
be required to specify a desired sequence of control.

This is perfectly clear and unambiguous albeit informal.




> Even though the parser may interpret it correctly,
> and that seems to be an outstanding question, 

only in the minds of some people.

the
> reader of the program may not.   Further, the original
> coder can certainly make a mistake with this quite
> easily, especially in the case of nested IF statements,
> where I have been observing this during my research.
>

No matter what "if ... then ... else ..." syntax is used is is easy to get 
confused.  That is why any coder with anything between his ears uses some sort 
of planning technique to design and implement complex logic.  Also the SELECT 
statement (or CASE or SWITCH in other languages) should be used in preference to 
IF for long sequences of the form

if c1 then s1;
else if c2 then s2;
else if c3 then s3;
....
0
jjw (608)
9/6/2006 9:29:13 PM
sven.axelsson@gmail.com wrote:
> Peter Flass wrote:
> 
>>adaworks@sbcglobal.net wrote:
>>
>>>"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
>>>news:mn%Kg.36257$uH6.32191@twister.nyroc.rr.com...
>>>
>>>
>>>>adaworks@sbcglobal.net wrote:
>>>
>>>
>>>Yet another question, in an attempt to clarify some
>>>points.
>>>
>>>In all the documentation I and programming examples I
>>>have been examining, it seems the IF statement is not
>>>accompnied by a corresponding END.  It is possible
>>>to put a DO ... END bracket around it but does not
>>>seem to be required by the compiler.
>>>
>>>I am sure that modern PL/I has probably corrected this
>>>potential for "dangling if" statements, but I cannot find the
>>>citation for it.   Fortran and COBOL corrected this
>>>a long time ago.  I am sure that, by now, PL/I has
>>>also corrected it.
>>
>>No.  Why is this a problem?
> 
> 
> It is not a problem if the grammar for the language unambigously
> specifies how the following is interpreted:
> 
> IF cond1 THEN stmt1; IF cond2 THEN stmt2; ELSE stmt3;
> 
> As long as the user (and the compiler) knows if the ELSE statement
> belongs to the first or the second IF, then there is no problem. Many
> languages do require a block construct in such cases, just to make it
> extra clear how this works, but that's just syntactic sugar.
> 
> And, by the way, I don't know how this is interpreted by PL/1, but I
> assume the ELSE associates with the last (closest) IF, right?
> 

Right.

0
Peter_Flass (956)
9/6/2006 11:06:52 PM
adaworks@sbcglobal.net wrote:
> I am sure that modern PL/I has probably corrected this
> potential for "dangling if" statements, but I cannot find the
> citation for it.   Fortran and COBOL corrected this
> a long time ago.  I am sure that, by now, PL/I has
> also corrected it.

Fortran had no proper structuring, and reasonably enough used the ENDIF 
approach when adding it. COBOL's first attempt at structuring was an 
abortion, and END-IF was a reasonable thing to include in the fix. Since 
PL/I, like ALGOL 60 before it and C and Java after it, already has 
structuring, upgrading to an ENDIF design has not been perceived as 
necessary. I freely admit that the ENDIF design is superior, but there's 
less impulse to implement it in languages where a major design change is 
not already necessary.

It's one of many things that I would include if I were briefed to design 
PL/II.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
9/7/2006 3:15:23 AM
John W. Kennedy wrote:

(snip)
 > I freely admit that the ENDIF design is superior, but there's
> less impulse to implement it in languages where a major design change is 
> not already necessary.

I probably agree in the case where there is more than one statement.

I think Fortran still allows the old logical IF with only
one statement and no ELSE.

-- glen

0
gah (12851)
9/7/2006 5:32:18 AM
"Tom Linden" <tom@kednos-remove.com> wrote in message 
news:op.tfgsafwutte90l@hyrrokkin...
> On Wed, 06 Sep 2006 08:39:13 -0700, <adaworks@sbcglobal.net> wrote:
>
> Richard, see my other post on this.  The DO -- END has nothing to
> do with the ENDIF construction which you are alluding, which is
> really sugar for a weak parser.  There really is no dangling IF
> issue in PL/I, you may have unbalance DO|BEGIN END groups, just
> as with braces in C
>
I think the DO...END block also makes clear, to the reader
of the program, the actual intent.   The ambiguity seems to
be, from reading the various fragments of code submitted in this
thread, to be a matter of readability rather than parsability
(if there were such a word).
>>
>>
>> Many newer languages have eliminated the need for
>> a DO ... END kind of delimiter by simply requiring
>> an END for every IF.   That, in turn has forced those
>> languages to add another construct, ELSEIF or
>> ELSIF, or something like it, to distinguish between
>> the original IF and a subordinate IF.  They use this
>> for multi-way selection (as opposed to the simple
>> alternation style selection of a standard IF).  In fact,
>> a few languages have eliminated the "case" (PL/I
>> SELECT) statement entirely in favor of the ELSIF
>> option.
>
> More gratuitous sugar.
>
I don't agree with that.  As I see it, the elsif or elseif,
improves readability of code.  Also, since most case
statements are designed over expressions that resolve
to a scalar, the elsif approach enables an alternative
to coding multi-way selection.
>>
> No, there is no ambiguity, see my other post.
>
Granted there is no ambiguity in the parser.  Given the
several attempts to write correct code for this and the
retractions and mea culpas over incorrect examples, it
seems to be more of a people problem than anything
else.  BTW, I have checked out the opinions in several
books on programming languages, and there seems to be
a unanimous agreement that the PL/I if statement is
ambiguous.   I have to trust your view on this since you
are a compiler writer and a PL/I expert and the authors
of the books are pretty much aping each other.  This
kind of thing happens all the time with programming
languages.   That is why I ask my questions here.  Also,
it is no always clear from a language reference manual
just what will really happen in a deployed implementation
of a compiler. I guess the people who write such
books need to be brought to a correct view.   Of course,
a lot of those books are quite old and the newer books
seem to ignore PL/I entirely.

Richard



0
adaworks2 (748)
9/7/2006 6:02:39 AM
adaworks@sbcglobal.net wrote:

(snip)

> I think the DO...END block also makes clear, to the reader
> of the program, the actual intent.   The ambiguity seems to
> be, from reading the various fragments of code submitted in this
> thread, to be a matter of readability rather than parsability
> (if there were such a word).

I once wrote, in a language that didn't have switch or select,
or any other multiway statement, a five level deep set of
nested IF statements.  At that point, even with the proper
indenting, it is hard to say that it is readable.


(snip)

> I don't agree with that.  As I see it, the elsif or elseif,
> improves readability of code.  Also, since most case
> statements are designed over expressions that resolve
> to a scalar, the elsif approach enables an alternative
> to coding multi-way selection.

I suppose if you do a linear set of if statements.
If they nest more than two deep, I don't think they
make it more readable, maybe less.

>>No, there is no ambiguity, see my other post.

> Granted there is no ambiguity in the parser. 

It is well known that C implemented in yacc has a
shift/reduce conflict that properly resolves as the
nearest enclosing if rule.  It is a warning message
that people get used to seeing.

-- glen

0
gah (12851)
9/7/2006 6:49:23 AM
adaworks@sbcglobal.net wrote:

> [...]
> Granted there is no ambiguity in the parser.  Given the
> several attempts to write correct code for this and the
> retractions and mea culpas over incorrect examples, it
> seems to be more of a people problem than anything
> else.  BTW, I have checked out the opinions in several
> books on programming languages, and there seems to be
> a unanimous agreement that the PL/I if statement is
> ambiguous.   I have to trust your view on this since you

It's completely unambiguous.  It is the same structure (with different
keywords and punctuation) as used by Algol 60 (Algol 68 added an "endif"
or "fi" or something similar), C, and the language poorly designed by
the great "St. Nik" himself: Pascal.

As for the several attempts and mea culpas, I suspect some of those 
postings were written hurriedly and the original mistakes were more a 
result of haste than of misunderstanding.

The structure is:

Example 1:

    if <expression> then <stmt1> [else <stmt2>]

It is a compound statement and each of <stmt1> and <stmt2> must be
single statements, though each can be a single compound statement.

Thus, in the case of

Example 2:

    if <expression1> then
       if <expression2> then <stmti>
       else <stmtj>

The "if <expression2> then <stmti> else <stmtj>", is the compound
statement that goes with the first "then" so that it takes the place of
<stmt1> in the first example and, hence, the "else" matches the second
"then".

If one wishes to match the "else" with the first (outer) "then", then
one would need to write it in this form:

Example 3:

    if <expression1> then
       do;  /* begins compound statement enclosing "if" statement */
          if <expression2> then <stmti>
       end;
    else <stmtj>  /* matches the first "then" */

(Well, the comments are optional :-) ).  Alternatively, you may
substitute "begin" for "do", but that creates a new declaration scope;
"do" does not.

IIRC, Algol and Pascal use "begin" ... "end", while C/C++ uses "{" ... "}".

I see no ambiguity though, in hindsight, I would have preferred an
"endif" to remove the need for the "do" ... "end" construct.

> are a compiler writer and a PL/I expert and the authors
> of the books are pretty much aping each other.  This
> kind of thing happens all the time with programming
> languages.   That is why I ask my questions here.  Also,
> it is no always clear from a language reference manual
> just what will really happen in a deployed implementation
> of a compiler. I guess the people who write such
> books need to be brought to a correct view.   Of course,
> a lot of those books are quite old and the newer books
> seem to ignore PL/I entirely.
> 
> Richard
> 
> 
> 
Bob Lidral
lidral  at  alum  dot  mit  dot  edu
0
9/7/2006 10:29:58 AM
adaworks@sbcglobal.net wrote:
> Also,
> it is no always clear from a language reference manual
> just what will really happen in a deployed implementation
> of a compiler. 

Having done this not too long ago, I thought both the manuals and the 
grammar were unambiguous.  The one thing I initially overlooked was the 
need to possibly terminate multiple conditionals at the end of a 
BEGIN-block or DO-group, thusly:

    DO i=1 to 5;
      IF a=1
         THEN IF b=2
              THEN ...
      END;

Where the END statement terminates all the IF-statements and the DO-group.

I guess the people who write such
> books need to be brought to a correct view.   Of course,
> a lot of those books are quite old and the newer books
> seem to ignore PL/I entirely.
> 

This is something that has to be corrected.  I appreciate your interest 
in PL/I.

0
Peter_Flass (956)
9/7/2006 10:32:39 AM
glen herrmannsfeldt wrote:
> I once wrote, in a language that didn't have switch or select,
> or any other multiway statement, a five level deep set of
> nested IF statements.  At that point, even with the proper
> indenting, it is hard to say that it is readable.

I don't have a hard and fast personal rule on this, but at a certain 
level of nesting I believe the code becomes unreadable, and it's time to 
pull out chunks into separate procedures - even a PROC which does some 
testing and returns '1'b or '0'b for the result of the tests.  I've also 
found this type of code easier to modify for complex sets of tests.

0
Peter_Flass (956)
9/7/2006 10:36:21 AM
Following up to <adaworks@sbcglobal.net> :

> As I see it, the elsif or elseif,
>improves readability of code. 

I disagree totally. 
-- 
Tim C.
0
9/7/2006 12:05:53 PM
glen herrmannsfeldt wrote in message ...
>Tim C. <tim.challenger@aon.at> wrote:
>
>>>And, by the way, I don't know how this is interpreted by PL/1, but I
>>>assume the ELSE associates with the last (closest) IF, right?
>
>> Correct:
>
>(snip of non-ambiguous IF statements)
>
>It gets ambiguous with something like:

It's not ambiguous, and doesn't get ambiguous.

>IF cond1 THEN
>   IF cond2 THEN stmt1;
>   ELSE stmt2;
>
>just like in C.  Similar to C, the solution is:
>
>IF cond1 THEN
>   IF cond2 THEN stmt1;
>   ELSE ;
>ELSE stmt2;

This is not a "solution".
The first snippet is unabiguous.


0
robin_v (2737)
9/7/2006 3:06:28 PM
sven.axelsson@gmail.com wrote in message <1157553671.732082.134120@p79g2000cwp.googlegroups.com>...
>
>sven.axelsson@gmail.com wrote:
>> It is not a problem if the grammar for the language unambigously
>> specifies how the following is interpreted:
>>
>> IF cond1 THEN stmt1; IF cond2 THEN stmt2; ELSE stmt3;
>
>Oops, typed too fast. The ambiguity occurs in this case:
>
>IF cond1 THEN; IF cond2 THEN stmt2; ELSE stmt3;

No, this is not ambiguous either.
There are two completely separate and unrelated IF statements :-

1.    IF cond1 THEN ;

2.    IF cond2 THEN stmt2; ELSE stmt3;


0
robin_v (2737)
9/7/2006 3:06:28 PM
sven.axelsson@gmail.com wrote in message <1157557301.811401.17950@h48g2000cwc.googlegroups.com>...
>
>Tom Linden wrote:
>> On Wed, 06 Sep 2006 07:41:11 -0700, sven.axelsson@gmail.com
>> <sven.axelsson@gmail.com> wrote:
>>
>> >
>> > sven.axelsson@gmail.com wrote:
>> >> It is not a problem if the grammar for the language unambigously
>> >> specifies how the following is interpreted:
>> >>
>> >> IF cond1 THEN stmt1; IF cond2 THEN stmt2; ELSE stmt3;
>> >
>> > Oops, typed too fast. The ambiguity occurs in this case:
>> >
>> > IF cond1 THEN; IF cond2 THEN stmt2; ELSE stmt3;
>>
>> > not as previously stated. But you all knew that already...
>>
>> No, there is no ambiguity  IF cond1 THEN;   is a no op because the
>> executable unit is a null statement.
>
>Yeah, well that was another slip of the finger. Serves me right for
>trying to use PL/1 syntax.
>
>IF cond1 THEN IF cond2 THEN stmt1; ELSE stmt2;

This is not ambiguous either (it's the same as the first example posted).


0
robin_v (2737)
9/7/2006 3:06:29 PM
adaworks@sbcglobal.net wrote in message ...
>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.
>
>When compared to most other contemporary languages I
>still find it lacking -- especially in OOP features.
>
>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.
>
>I would be happy to include it in my discussion of OOP languages
>if there is an real implementation out there somewhere.

Some of the things that can be done in PL/I include the following
(each is an example of a valid PL/I source statement):

Examples:
get (B);    Read a matrix, [this statement also reads in the dimensions of the matrix)
put (B);    Print a matrix.
A = N identity;  Generate a unit matrix of order N, and assign it to A.
A = B transpose; Transpose matrix B, and assign it to matrix A.
X = B solve;  Solve the equations stored in B, storing the solutions in X.
A = B x C;  Matrix multiplication of B and C.
A = B invert;  Invert matrix B, and assign the result to matrix A.
A = B attach C;  Columns of B are followed by columns of C and are assigned to A.
A = B attach_rows C; Rows of B are followed by rows of C, and are assigned to A.
A = B sin;  The sine of B is assigned to A.


0
robin_v (2737)
9/7/2006 3:06:30 PM
adaworks@sbcglobal.net wrote in message ...
>
>"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
>news:mn%Kg.36257$uH6.32191@twister.nyroc.rr.com...
>> adaworks@sbcglobal.net wrote:
>
>In all the documentation I and programming examples I
>have been examining, it seems the IF statement is not
>accompnied by a corresponding END.  It is possible
>to put a DO ... END bracket around it but does not
>seem to be required by the compiler.

An IF statement requires an IF and THEN, and an optional ELSE.

A DO / END, if used, is included as either or both of the
optionally executed segments, not around the IF statement.

>I am sure that modern PL/I has probably corrected this
>potential for "dangling if" statements, but I cannot find the
>citation for it.   Fortran and COBOL corrected this
>a long time ago.

As for Fortran, there was nothing to "correct".  Fortran conditionals
were never ambiguous.
The basic ones were     IF (AE) s1, s2, s3
and       IF (logical expr) stmt

A Block IF statement was added to Fortran - IF ELSE END IF.

>  I am sure that, by now, PL/I has
>also corrected it.
>
>Any thoughts.
>
>Richard Riehle


0
robin_v (2737)
9/7/2006 3:06:30 PM

adaworks@sbcglobal.net wrote:
> "Tom Linden" <tom@kednos-remove.com> wrote in message 
> news:op.tfgsafwutte90l@hyrrokkin...
> 
>>On Wed, 06 Sep 2006 08:39:13 -0700, <adaworks@sbcglobal.net> wrote:
>>
>>Richard, see my other post on this.  The DO -- END has nothing to
>>do with the ENDIF construction which you are alluding, which is
>>really sugar for a weak parser.  There really is no dangling IF
>>issue in PL/I, you may have unbalance DO|BEGIN END groups, just
>>as with braces in C
>>
> 
> I think the DO...END block also makes clear, to the reader
> of the program, the actual intent.   The ambiguity seems to
> be, from reading the various fragments of code submitted in this
> thread, to be a matter of readability rather than parsability
> (if there were such a word).
> 
>>>
>>>Many newer languages have eliminated the need for
>>>a DO ... END kind of delimiter by simply requiring
>>>an END for every IF.   That, in turn has forced those
>>>languages to add another construct, ELSEIF or
>>>ELSIF, or something like it, to distinguish between
>>>the original IF and a subordinate IF.  They use this
>>>for multi-way selection (as opposed to the simple
>>>alternation style selection of a standard IF).  In fact,
>>>a few languages have eliminated the "case" (PL/I
>>>SELECT) statement entirely in favor of the ELSIF
>>>option.
>>
>>More gratuitous sugar.
>>
> 
> I don't agree with that.  As I see it, the elsif or elseif,
> improves readability of code.  Also, since most case
> statements are designed over expressions that resolve
> to a scalar, the elsif approach enables an alternative
> to coding multi-way selection.
> 
>>No, there is no ambiguity, see my other post.
>>
> 
> Granted there is no ambiguity in the parser.  Given the
> several attempts to write correct code for this and the
> retractions and mea culpas over incorrect examples, it
> seems to be more of a people problem than anything
> else.  BTW, I have checked out the opinions in several
> books on programming languages, and there seems to be
> a unanimous agreement that the PL/I if statement is
> ambiguous.  

I disagree.  What the manual says and what the compiler does is precise 
and unambiguous.  The only ambiguity is in the mind of the reader (or 
coder) who hasn't bothered to RTM or learn the language.

  I have to trust your view on this since you
> are a compiler writer and a PL/I expert and the authors
> of the books are pretty much aping each other.  This
> kind of thing happens all the time with programming
> languages.   That is why I ask my questions here.  Also,
> it is no always clear from a language reference manual
> just what will really happen in a deployed implementation
> of a compiler. I guess the people who write such
> books need to be brought to a correct view.   Of course,
> a lot of those books are quite old and the newer books
> seem to ignore PL/I entirely.
> 
> Richard
> 
> 
> 
0
donaldldobbs (108)
9/7/2006 5:32:53 PM
Bob Lidral wrote:
> 
> If one wishes to match the "else" with the first (outer) "then", then
> one would need to write it in this form:
> 
> Example 3:
> 
>    if <expression1> then
>       do;  /* begins compound statement enclosing "if" statement */
>          if <expression2> then <stmti>
>       end;
>    else <stmtj>  /* matches the first "then" */
> 
> (Well, the comments are optional :-) ).  Alternatively, you may
> substitute "begin" for "do", but that creates a new declaration scope;
> "do" does not.
> 
One could also write:

  if e1 then if e2 then si; else; else sj;
0
jjw (608)
9/7/2006 6:20:26 PM
Bob Lidral <l1dralspamba1t@comcast.net> wrote:
(big snip of nested IF statements)
 
> If one wishes to match the "else" with the first (outer) "then", then
> one would need to write it in this form:
 
> Example 3:
 
>    if <expression1> then
>       do;  /* begins compound statement enclosing "if" statement */
>          if <expression2> then <stmti>
>       end;
>    else <stmtj>  /* matches the first "then" */

The alternative is an ELSE with a null statement.  I won't comment
on which is more readable without a specific example.
 
> (Well, the comments are optional :-) ).  Alternatively, you may
> substitute "begin" for "do", but that creates a new declaration scope;
> "do" does not.
 
> IIRC, Algol and Pascal use "begin" ... "end", while C/C++ uses "{" ... "}".

As I understand it, in those languages the begin may or may not
add a new scoping level.  
 
> I see no ambiguity though, in hindsight, I would have preferred an
> "endif" to remove the need for the "do" ... "end" construct.

If the majority of IF statements have many statements in the
THEN or ELSE part, I would agree.  I am not sure that they do.

-- glen

 
0
gah1 (524)
9/7/2006 6:56:30 PM
adaworks@sbcglobal.net wrote:

> In all the documentation I and programming examples I
> have been examining, it seems the IF statement is not
> accompnied by a corresponding END. 

Well the IF statement has to be terminated with a ';', so in that sense
there is no dangling ELSE nor IF problem.

In fact with the bison grammar, I have modelled ELSE as a statement on its
own, and the same goes for SELECT, WHEN and OTHERWISE. The statements can
of course only occur in a certain context.
> Richard Riehle
Henrik

0
9/7/2006 8:09:43 PM
"Tim C." <tim.challenger@aon.at> wrote in message 
news:co20g2tl59fartqh4u4n1o39f1k1fkjego@4ax.com...
> Following up to <adaworks@sbcglobal.net> :
>
>> As I see it, the elsif or elseif,
>>improves readability of code.
>
> I disagree totally.
> -- 
How would you code the following?

if  condition-1 then
               procedure-1;
               procedure-2;
   elsif  condition-2 then
              procedure-2;
              procedure-3;
   elsif condition-3 then
              procedure-3;
              procedure-4;
   else      procedure-5;
end if;

This is a simple multi-way selection.  In many cases,
it is more appropriate to use a case (PL/I select) statement.
However, if the condition does not resolve to a boolean or
a scalar, in most languages, a case statement is not allowed.
For example if we are testing floating-point values, this
generally works better than a case statement.

The code I show is typical of quite a few contemporary languages
except for those in the C family.    In fact, several language designers
have decided to use this construct instead of including a case
statement.  There is no limit to the number of elsif/elseif/or-if
conditions.   And it is very easy to read and follow.  This
is not the same as nesting if statements.  Nesting would look
like the following.

if condition-1 then
   procedure-1;
   if condition-2 then
      procedure-3;
      procedure-4;
      if condition-3 then
         procedure-5;
         procedure-6;
      end if;
   end if;
end if;

In the above example, the nesting is quite clearly demarcated
with the end if.   This seems to be the situation where the
DO ... END is required in  PL/I.   Or is it?

Richard 


0
adaworks2 (748)
9/8/2006 5:27:37 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:WzWLg.24937$rP1.8043@news-server.bigpond.net.au...
>
> As for Fortran, there was nothing to "correct".  Fortran conditionals
> were never ambiguous.
> The basic ones were     IF (AE) s1, s2, s3
> and       IF (logical expr) stmt
>
> A Block IF statement was added to Fortran - IF ELSE END IF.
>
Those charged with updating Fortran over the last several versions
seem to have had a different opinion since they saw the value of
adding an End If to the conditional construct.

Many PL/I programmers also seem to see the value of bracketing
a multiple statement IF construct with a DO ... BEGIN.   I am not
criticizing the language.  The fact that this option is available is a
good thing, not a bad thing.

Richard 


0
adaworks2 (748)
9/8/2006 5:31:08 AM
glen herrmannsfeldt wrote:

> Bob Lidral <l1dralspamba1t@comcast.net> wrote:
> (big snip of nested IF statements)
>>[...]
>>(Well, the comments are optional :-) ).  Alternatively, you may
>>substitute "begin" for "do", but that creates a new declaration scope;
>>"do" does not.
> 
>  
> 
>>IIRC, Algol and Pascal use "begin" ... "end", while C/C++ uses "{" ... "}".
> 
> 
> As I understand it, in those languages the begin may or may not
> add a new scoping level.  
>  
You're correct; they create a new scoping level iff they contain 
declarations at their outermost level.  Until you mentioned it, though, 
I hadn't realized my comments about "begin" ... "end" in PL/I might have 
created an ambiguity in my comments about Algol, Pascal, and C/C++. 
Sorry 'bout that.

>>I see no ambiguity though, in hindsight, I would have preferred an
>>"endif" to remove the need for the "do" ... "end" construct.
> 
> 
> If the majority of IF statements have many statements in the
> THEN or ELSE part, I would agree.  I am not sure that they do.
> 
> -- glen
> 
>  
It's not so much "many" statements as two or more statements.  Part of 
my preference is personal aesthetic taste, part based on my experience 
helping debug lots of student programs, and part based on how much 
easier it would make it to insert and remove debugging output statements.


Bob Lidral
lidral  at  alum  dot  mit  dot  edu
0
9/8/2006 5:36:26 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:WzWLg.24936$rP1.12157@news-server.bigpond.net.au...
>
> Some of the things that can be done in PL/I include the following
> (each is an example of a valid PL/I source statement):
>
> Examples:
> get (B);    Read a matrix, [this statement also reads in the dimensions of the 
> matrix)
> put (B);    Print a matrix.
> A = N identity;  Generate a unit matrix of order N, and assign it to A.
> A = B transpose; Transpose matrix B, and assign it to matrix A.
> X = B solve;  Solve the equations stored in B, storing the solutions in X.
> A = B x C;  Matrix multiplication of B and C.
> A = B invert;  Invert matrix B, and assign the result to matrix A.
> A = B attach C;  Columns of B are followed by columns of C and are assigned to 
> A.
> A = B attach_rows C; Rows of B are followed by rows of C, and are assigned to 
> A.
> A = B sin;  The sine of B is assigned to A.
>
Good examples.  However, they are not unique to PL/I.   On the other hand, PL/I
was one of the earliest languages to provide this kind of thing.   Many modern
programming languages learned a lot from the early problems of PL/I.   PL/I,
over the years has also changed to deal with the many criticisms from the larger
software community.

My original question had to do with support for object-oriented programming
in deployed, operational version of PL/I.

Several respondents have suggested that one can do OOP in PL/I using existing
constructs.   This is something of a stretch.   In particular, dynamic 
polymorphism
would be quite difficult with the existing standard.   Extensible inheritance is 
next
to impossible without jumping through a lot of hoops.   When I say extensible
inheritance, I mean being able to extend an existing data item (including
encapsulated methods) without touching any of the existing code.

Now, it is certainly true that not every programming problem needs to be, or
even should be, written using OOP.   Inheritance is often overworked, and
even more often misused.   Dynamic polymorphism carries some serious
safety concerns and is inappropriate for embedded safety-critical software.
Lots of other popular mechanisms in object-oriented programming, especially
in C++, are inherently dangerous.   There is still a role for good old-fashioned
structured/procedural programming and PL/I can fill a niche in that domain.

I do believe, however, that PL/I would benefit from a conscientious design
effort to bring an OOP standard into existence.  Otherwise, it will continue
to be ignored by the larger programming community.  On the other hand,
a well-publicized, widely available OOP version of PL/I that is available
for a larger number of platforms would breathe new life into the language
and get the attention of a whole new generation of programmers.  Is that
a worthwhile goal?

Richard Riehle
touching any part of the 


0
adaworks2 (748)
9/8/2006 5:45:55 AM
henrik.sorensen@balcab.ch wrote:

> adaworks@sbcglobal.net wrote:
> 
> 
>>"Tim C." <tim.challenger@aon.at> wrote in message
>>news:co20g2tl59fartqh4u4n1o39f1k1fkjego@4ax.com...
>>
>>>Following up to <adaworks@sbcglobal.net> :
>>>
>>>
>>>>As I see it, the elsif or elseif,
>>>>improves readability of code.
>>>
>>>I disagree totally.
>>>--
>>
>>How would you code the following?
>>
>>if  condition-1 then
>>               procedure-1;
>>               procedure-2;
>>   elsif  condition-2 then
>>              procedure-2;
>>              procedure-3;
>>   elsif condition-3 then
>>              procedure-3;
>>              procedure-4;
>>   else      procedure-5;
>>end if;
> 
> 
> if condition-1 then 
>   do;
>     procedure-1
>     procedure-2
>   end;
> else if condition-2 then
>   do;
>     procedure-2
>     procedure-3
>   end;
> else if condition-2 then
>   do;
>     procedure-3
>     procedure-4
     end;
   else
     do;
>     procedure-5
>   end;
> 
> I dont see the need for a elseif either. It seems pointless to define a new
> keyword just to save a space.
> 
> Henrik

Adding the "elseif" would make it a single compound statement instead of 
a several nested compound statements.  What you've written above could 
also be indented as follows to illustrate the statement nesting:

if condition-1 then
   do;
     procedure-1
     procedure-2
   end;
else
   if condition-2 then
     do;
       procedure-2
       procedure-3
     end;
   else
     if condition-2 then
       do;
         procedure-3
         procedure-4
       end;
     else
       do;
         procedure-5
       end;

Though I prefer your original indentation convention for a string of "if 
.... else if ... else if ... else ..." statements since it makes the 
programming intent (as opposed to the syntax structure) clearer and is 
no less readable than it would be with a true "elseif".


Bob Lidral
lidral  at  alum  dot  mit  dot  edu
0
9/8/2006 9:20:39 AM
adaworks@sbcglobal.net wrote:

> 
> "Tim C." <tim.challenger@aon.at> wrote in message
> news:co20g2tl59fartqh4u4n1o39f1k1fkjego@4ax.com...
>> Following up to <adaworks@sbcglobal.net> :
>>
>>> As I see it, the elsif or elseif,
>>>improves readability of code.
>>
>> I disagree totally.
>> --
> How would you code the following?
> 
> if  condition-1 then
>                procedure-1;
>                procedure-2;
>    elsif  condition-2 then
>               procedure-2;
>               procedure-3;
>    elsif condition-3 then
>               procedure-3;
>               procedure-4;
>    else      procedure-5;
> end if;

if condition-1 then 
  do;
    procedure-1
    procedure-2
  end;
else if condition-2 then
  do;
    procedure-2
    procedure-3
  end;
else if condition-2 then
  do;
    procedure-3
    procedure-4
    procedure-5
  end;

I dont see the need for a elseif either. It seems pointless to define a new
keyword just to save a space.

Henrik
0
9/8/2006 9:41:10 AM
adaworks@sbcglobal.net wrote:

> "robin" <robin_v@bigpond.com> wrote in message 
> news:WzWLg.24937$rP1.8043@news-server.bigpond.net.au...
> 
>>As for Fortran, there was nothing to "correct".  Fortran conditionals
>>were never ambiguous.
>>The basic ones were     IF (AE) s1, s2, s3
>>and       IF (logical expr) stmt
>>
>>A Block IF statement was added to Fortran - IF ELSE END IF.
>>
> 
> Those charged with updating Fortran over the last several versions
> seem to have had a different opinion since they saw the value of
> adding an End If to the conditional construct.
> 
> Many PL/I programmers also seem to see the value of bracketing
> a multiple statement IF construct with a DO ... BEGIN.   I am not
> criticizing the language.  The fact that this option is available is a
> good thing, not a bad thing.

(I'll assume you meant "DO ... END".  :-) )  Actually, though, it's not 
an option in PL/I -- it's required.  That is:

if <condition> then
    stmt1;
    stmt2;

only executes stmt1 under control of the conditional; stmt2 is always 
executed (unless, of course, stmt1 alters the flow of control).  That 
is, the short segment above is misleadingly indented.  The more accurate 
indentation would be:

if <condition> then
    stmt1;
stmt2;

To achieve the behavior implied by the indentation in the first example, 
the "do ... end" grouping is necessary, not optional, in PL/I:

if <condition> then
   do;
     stmt1;
     stmt2;
   end;


As for Fortran, since FORTRAN IV (the 1966 standard), FORTRAN has had a 
single-statement (logical) IF.  When the 1977 standard was first 
proposed (March, 1976), there was no improvement to the IF statement. 
The IF ... [ELSE ...] ENDIF was only added after the users complained 
long and loudly about its omission.  Good thing, too -- the next 
standard didn't come out for another 13 years.

I don't remember seeing an "endif" bracketing structure in any language 
definition before Algol 68 or RATFOR (whichever came first) (oh, and 
don't forget the Bourne shell), all of which came after the design of 
PL/I.  When IF ... [ELSE ...] ENDIF was added to FORTRAN in 1977, 
FORTRAN had no equivalent to PL/I's do ... end group but they had the 
example of Algol 68, RATFOR, and a few other languages.  Today's Fortran 
programmers should just be glad the committee didn't decide to pattern 
it after the original FORTRAN DO statement, e.g. :-) :

       IF 10 (<logical expression>)
           .
           .
           .
       ELSE 10
           .
           .
           .
    10 CONTINUE

I actually saw one proposal in the ACM's SIG or SIC for Fortran that 
suggested associating the IF, ELSE, and ENDIF keywords with each other 
by starting column number -- that is, if they started in exactly the 
same column (these were the days of computer cards) in each of their 
respective lines, then they would be matched up -- otherwise they 
wouldn't (and the IF would be interpreted as a single-statement IF and 
both the ELSE and ENDIF would be syntax errors).  I'm not sure how 
serious this was.  Although it appeared to be written seriously, I think 
it appeared in the April issue that year.


Bob Lidral
lidral  at  alum  dot  mit  dot  edu
0
9/8/2006 9:50:23 AM
adaworks@sbcglobal.net wrote:
>  In many cases,
> it is more appropriate to use a case (PL/I select) statement.
> However, if the condition does not resolve to a boolean or
> a scalar, in most languages, a case statement is not allowed.
> For example if we are testing floating-point values, this
> generally works better than a case statement.
> 

You're probably aware that the PL/I SELECT is more general even than 
that.  You can code the equivalent of IF..THEN..ELSEI as follows:

   SELECT; /* Notice no <expression> on SELECT */
     WHEN(first_condition) DO;
       ...
       END;
     WHEN(second_condition) DO;
       ...
       END;

where the xxx_condition can be anything.  The condition expression is 
evaluated and converted to a BIT(1) if necessary.  If TRUE (i.e. '1'b), 
the statements in the corresponding DO ... END group are executed and 
the rest of the SELECT is skipped.

0
Peter_Flass (956)
9/8/2006 10:33:22 AM
In <1f44e$45011e63$5448c618$12330@news.hispeed.ch>, on 09/08/2006
   at 09:41 AM, henrik.sorensen@balcab.ch said:

>if condition-1 then 
>  do;
>    procedure-1
>    procedure-2
>  end;
>else if condition-2 then
>  do;
>    procedure-2
>    procedure-3
>  end;
>else if condition-2 then
>  do;
>    procedure-3
>    procedure-4
>    procedure-5
>  end;

In PL/I (F), yes; not in any current PL/I. I'd use the SELECT
statement, with an OTHERWISE, which would make it easier on
prettyprinters. Note; I've corrected some apparent typos[1] in your
version, and no doubt introduced some of my own.

select;
  when condition-1 then 
    do;
      procedure-1;
      procedure-2;
    end;
  when condition-2 then
    do;
      procedure-2;
      procedure-3;
    end;
  when condition-3 then
    do;
      procedure-3;
      procedure-4;
    end;
  otherwise
    procedure-5;
end;

[1] "condition-2" repeated and condition-3" missing; "procedure-5"
    in the 3rd "then do" instead of in an else clause.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
9/8/2006 11:42:54 AM
On Thu, 07 Sep 2006 22:36:26 -0700, Bob Lidral  
<l1dralspamba1t@comcast.net> wrote:

> glen herrmannsfeldt wrote:
>
>> Bob Lidral <l1dralspamba1t@comcast.net> wrote:
>> (big snip of nested IF statements)
>>> [...]
>>> (Well, the comments are optional :-) ).  Alternatively, you may
>>> substitute "begin" for "do", but that creates a new declaration scope;
>>> "do" does not.
>>
>>> IIRC, Algol and Pascal use "begin" ... "end", while C/C++ uses "{" ...  
>>> "}".
>>   As I understand it, in those languages the begin may or may not
>> add a new scoping level.
> You're correct; they create a new scoping level iff they contain  
> declarations at their outermost level.  Until you mentioned it, though,  
> I hadn't realized my comments about "begin" ... "end" in PL/I might have  
> created an ambiguity in my comments about Algol, Pascal, and C/C++.  
> Sorry 'bout that.

To be a bit more clear, declarations appearing inside the BEGIN-END have
local meaning.  In any event a new stack frame is created.  I have seen  
programs
where BEGIN was used extensively when DO would have sufficed, resulting in
rather poor perfomance.

>
>>> I see no ambiguity though, in hindsight, I would have preferred an
>>> "endif" to remove the need for the "do" ... "end" construct.
>>   If the majority of IF statements have many statements in the
>> THEN or ELSE part, I would agree.  I am not sure that they do.
>>  -- glen
>>
> It's not so much "many" statements as two or more statements.  Part of  
> my preference is personal aesthetic taste, part based on my experience  
> helping debug lots of student programs, and part based on how much  
> easier it would make it to insert and remove debugging output statements.
>
>
> Bob Lidral
> lidral  at  alum  dot  mit  dot  edu



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/8/2006 12:20:44 PM
Bob Lidral wrote:

> henrik.sorensen@balcab.ch wrote:
> 
>> adaworks@sbcglobal.net wrote:
>> 
>> 
>>>"Tim C." <tim.challenger@aon.at> wrote in message
>>>news:co20g2tl59fartqh4u4n1o39f1k1fkjego@4ax.com...
>>>
>>>>Following up to <adaworks@sbcglobal.net> :
>>>>
>>>>
>>>>>As I see it, the elsif or elseif,
>>>>>improves readability of code.
>>>>
>>>>I disagree totally.
>>>>--
>>>
>>>How would you code the following?
>>>
>>>if  condition-1 then
>>>               procedure-1;
>>>               procedure-2;
>>>   elsif  condition-2 then
>>>              procedure-2;
>>>              procedure-3;
>>>   elsif condition-3 then
>>>              procedure-3;
>>>              procedure-4;
>>>   else      procedure-5;
>>>end if;
>> 
>> 
>> if condition-1 then
>>   do;
>>     procedure-1
>>     procedure-2
>>   end;
>> else if condition-2 then
>>   do;
>>     procedure-2
>>     procedure-3
>>   end;
>> else if condition-2 then
>>   do;
>>     procedure-3
>>     procedure-4
>      end;
>    else
>      do;
>>     procedure-5
>>   end;
>> 
>> I dont see the need for a elseif either. It seems pointless to define a
>> new keyword just to save a space.
>> 
>> Henrik
> 
> Adding the "elseif" would make it a single compound statement instead of
> a several nested compound statements. 

true, but misses the point that ELSE already is a single compound statement
if you want. Of course ELSE can only occur in a specific context.

> What you've written above could 
> also be indented as follows to illustrate the statement nesting:
but here the nesting does nothing to help the read of the program.

> 
> Though I prefer your original indentation convention for a string of "if
> ... else if ... else if ... else ..." statements since it makes the
> programming intent (as opposed to the syntax structure) clearer and is
> no less readable than it would be with a true "elseif".
ok, I see we agree.

Henrik
0
9/8/2006 12:27:05 PM
On Fri, 08 Sep 2006 03:33:22 -0700, Peter Flass <Peter_Flass@Yahoo.com>  
wrote:

> adaworks@sbcglobal.net wrote:
>>  In many cases,
>> it is more appropriate to use a case (PL/I select) statement.
>> However, if the condition does not resolve to a boolean or
>> a scalar, in most languages, a case statement is not allowed.
>> For example if we are testing floating-point values, this
>> generally works better than a case statement.
>>
>
> You're probably aware that the PL/I SELECT is more general even than  
> that.  You can code the equivalent of IF..THEN..ELSEI as follows:
>
>    SELECT; /* Notice no <expression> on SELECT */
>      WHEN(first_condition) DO;
>        ...
>        END;
>      WHEN(second_condition) DO;
>        ...
>        END;
>
> where the xxx_condition can be anything.  The condition expression is  
> evaluated and converted to a BIT(1) if necessary.  If TRUE (i.e. '1'b),  
> the statements in the corresponding DO ... END group are executed and  
> the rest of the SELECT is skipped.
>

Or, just to complete the picture using label array

go to case(i);

case(1): do;
          end;
case(2): do;
          end;
..
..
..
case(*): do;  /* Equivalent tgo otherwise or default */
          end;





-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/8/2006 12:27:22 PM
On Thu, 07 Sep 2006 22:45:55 -0700, <adaworks@sbcglobal.net> wrote:

> Now, it is certainly true that not every programming problem needs to  
> be, or
> even should be, written using OOP.   Inheritance is often overworked, and
> even more often misused.   Dynamic polymorphism carries some serious
> safety concerns and is inappropriate for embedded safety-critical  
> software.
> Lots of other popular mechanisms in object-oriented programming,  
> especially
> in C++, are inherently dangerous.   There is still a role for good  
> old-fashioned
> structured/procedural programming and PL/I can fill a niche in that  
> domain.

Richard, could you expound on those points?  If it is unsafe in one
area, why is it not unsafe in any area.  Encapsulation is another
method that has gone to the ridiculous extreme.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/8/2006 12:40:28 PM
On Fri, 08 Sep 2006 04:42:54 -0700, Shmuel (Seymour J.) Metz  
<spamtrap@library.lspace.org.invalid> wrote:

> In <1f44e$45011e63$5448c618$12330@news.hispeed.ch>, on 09/08/2006
>    at 09:41 AM, henrik.sorensen@balcab.ch said:
>
>> if condition-1 then
>>  do;
>>    procedure-1
>>    procedure-2
>>  end;
>> else if condition-2 then
>>  do;
>>    procedure-2
>>    procedure-3
>>  end;
>> else if condition-2 then
>>  do;
>>    procedure-3
>>    procedure-4
>>    procedure-5
>>  end;
>
> In PL/I (F), yes; not in any current PL/I. I'd use the SELECT
> statement, with an OTHERWISE, which would make it easier on
> prettyprinters. Note; I've corrected some apparent typos[1] in your
> version, and no doubt introduced some of my own.
>
> select;
>   when condition-1 then
>     do;
>       procedure-1;
>       procedure-2;
>     end;
>   when condition-2 then
>     do;
>       procedure-2;
>       procedure-3;
>     end;
>   when condition-3 then
>     do;
>       procedure-3;
>       procedure-4;
>     end;
>   otherwise
>     procedure-5;
> end;
>
> [1] "condition-2" repeated and condition-3" missing; "procedure-5"
>     in the 3rd "then do" instead of in an else clause.
>

<PEDANTIC> Instead of "Procedure" you should use "Executable-unit"  
</PEDANTIC>

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/8/2006 1:59:45 PM
Shmuel (Seymour J.) Metz wrote:

> In <1f44e$45011e63$5448c618$12330@news.hispeed.ch>, on 09/08/2006
>    at 09:41 AM, henrik.sorensen@balcab.ch said:
> 
>>if condition-1 then
>>  do;
>>    procedure-1
>>    procedure-2
>>  end;
>>else if condition-2 then
>>  do;
>>    procedure-2
>>    procedure-3
>>  end;
>>else if condition-2 then
>>  do;
>>    procedure-3
>>    procedure-4
>>    procedure-5
>>  end;
> 
> In PL/I (F), yes; not in any current PL/I. 
to the best of my knowledge, IF ... THEN ... ; ELSE IF ... is still part of
PL/I, even to most recent versions :-)


> I'd use the SELECT 
that would work as well

Henrik
0
9/8/2006 4:23:47 PM
<henrik.sorensen@balcab.ch> wrote in message 
news:1f44e$45011e63$5448c618$12330@news.hispeed.ch...
> adaworks@sbcglobal.net wrote:
>
>>
>> "Tim C." <tim.challenger@aon.at> wrote in message
>> news:co20g2tl59fartqh4u4n1o39f1k1fkjego@4ax.com...
>>> Following up to <adaworks@sbcglobal.net> :
>>>
>>>> As I see it, the elsif or elseif,
>>>>improves readability of code.
>>>
>>> I disagree totally.
>>> --
>> How would you code the following?
>>
>> if  condition-1 then
>>                procedure-1;
>>                procedure-2;
>>    elsif  condition-2 then
>>               procedure-2;
>>               procedure-3;
>>    elsif condition-3 then
>>               procedure-3;
>>               procedure-4;
>>    else      procedure-5;
>> end if;
>
> if condition-1 then
>  do;
>    procedure-1
>    procedure-2
>  end;
> else if condition-2 then
>  do;
>    procedure-2
>    procedure-3
>  end;
> else if condition-2 then
>  do;
>    procedure-3
>    procedure-4
>    procedure-5
>  end;
>
> I dont see the need for a elseif either. It seems pointless to define a new
> keyword just to save a space.
>
Actually, your example is not quite the same.  The elsif is a true multi-way 
statement,
similar to a case/select/switch statement, but with an if.   It is not simply a 
way of
saving space.   When the case statement was first introduced, a lot of people
also saw it as a waste.  We have come to realize that multi-way statements do
have value.

Richard 


0
adaworks2 (748)
9/8/2006 4:49:06 PM
adaworks@sbcglobal.net wrote:

> Those charged with updating Fortran over the last several versions
> seem to have had a different opinion since they saw the value of
> adding an End If to the conditional construct.

Yes, but they didn't remove the non-block IF.

     IF(A.LT.0.) A=0.

or

     IF(A.LT.0.) THEN
        A=0.
     ENDIF

Compare to:

     IF A<0 THEN A=0;

     IF A<0 THEN DO;
        A=0;
     END;


-- glen
0
gah1 (524)
9/8/2006 4:52:06 PM
Bob Lidral <l1dralspamba1t@comcast.net> wrote:
 
> I actually saw one proposal in the ACM's SIG or SIC for Fortran that 
> suggested associating the IF, ELSE, and ENDIF keywords with each other 
> by starting column number -- that is, if they started in exactly the 
> same column (these were the days of computer cards) in each of their 
> respective lines, then they would be matched up -- otherwise they 
> wouldn't 

That sounds a little like I understand Python does.

Indenting levels are used by the compiler to indicate nesting
levels.  

I haven't actually written any Python code, so I don't know the
exact details.

-- glen
0
gah1 (524)
9/8/2006 4:55:46 PM
On Fri, 08 Sep 2006 09:55:46 -0700, glen herrmannsfeldt  
<gah@seniti.ugcs.caltech.edu> wrote:

> Bob Lidral <l1dralspamba1t@comcast.net> wrote:
>
>> I actually saw one proposal in the ACM's SIG or SIC for Fortran that
>> suggested associating the IF, ELSE, and ENDIF keywords with each other
>> by starting column number -- that is, if they started in exactly the
>> same column (these were the days of computer cards) in each of their
>> respective lines, then they would be matched up -- otherwise they
>> wouldn't
>
> That sounds a little like I understand Python does.
>
> Indenting levels are used by the compiler to indicate nesting
> levels.
>
> I haven't actually written any Python code, so I don't know the
> exact details.
>
> -- glen

If you supply the correct options the compiler will display the nesting  
levels for you in the list file


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/8/2006 5:14:07 PM
"Tom Linden" <tom@kednos-remove.com> wrote in message 
news:op.tfj75qr2tte90l@hyrrokkin...
> On Thu, 07 Sep 2006 22:45:55 -0700, <adaworks@sbcglobal.net> wrote:
>
>> Now, it is certainly true that not every programming problem needs to  be, or
>> even should be, written using OOP.   Inheritance is often overworked, and
>> even more often misused.   Dynamic polymorphism carries some serious
>> safety concerns and is inappropriate for embedded safety-critical  software.
>> Lots of other popular mechanisms in object-oriented programming,  especially
>> in C++, are inherently dangerous.   There is still a role for good 
>> old-fashioned
>> structured/procedural programming and PL/I can fill a niche in that  domain.
>
> Richard, could you expound on those points?  If it is unsafe in one
> area, why is it not unsafe in any area.  Encapsulation is another
> method that has gone to the ridiculous extreme.
>
Dynamic binding is based on the idea that each method invocation is
resolved at the time of execution.   This is an excellent approach to
programs that can afford to sometimes (rarely, I admit) get it wrong
or try to invoke a method that does not exist.  Exception handling
can deal with that nicely.

When combined with polymorphism, this works almost like a dynamic
case statement.   It is usually built over the inheritance model and
involves overriding of methods (same name, extended behavior).
Frequently, it also involves liberal use of pointers and dynamic
allocation of memory.

In the safety-critical world, where I spent part of my career, and
still consult from time to time, we demand a high-level of
predictability.    As the inheritance tree grows larger, it becomes
more difficult, in a dynamic polymorphism model, to have confidence
in the level of predictability -- it is harder to prove a program correct.

Consider the example of a very clever piece of software written to
manage an operating room during surgery.   It had to be rebooted
from time to time.  Exception-handling can help, but safety-critical
software does not encourage reliance on this mechanism.

Some OOP environments are emerging, due to improvements in
language design, that are more amenable to safety-critical software,
but we still have a way to go before the safety-critical community
is entirely satisfied.

One advance that is helping a lot is the application of the Hoare
Triplet.  This is an assertion model overlaid onto the programming
language.  It is a powerful tool which allows one to build specifications
into the program for checking key constructs prior to invocation, and at
completion of processing.   Add to that the invariant assertion and one
has a very powerful set of tools for improving dependability.

A few languages have good assertion capabilities.  One of the best, at
this time, is Eiffel.

However, in the safety-critical world, assertions need to be shown to be
correct, not at run-time, but at development time  -- before deployment.
This is a very difficult problem, but some of the best and brightest minds
in the computing industry have been making significant advances in this
direction over the past ten years.

That last paragraph goes back to the original statement.  In the world of
safety-critical software, we don't want any chance of an error occurring
at run-time.   We want to be able to establish the validity of every
construct through the combination of good design principles, good
development tools, and good developers.  Any level of unpredictability
is unacceptable.

We are not yet at the point where we have reached the goal at the level
anyone would prefer.   However, the current state-of-the-art, over the
past ten years, has demonstrated remarkable results.  In particular, the
SPARK approach (which does not permit dynamic binding or dynamic
polymorphism, but does have limited support for inheritance) has shown
that we can achieve a lot of our goals.

I hope this helps.  I am certainly willing to answer any other questions
about this if you are interested.

Richard 


0
adaworks2 (748)
9/8/2006 5:15:54 PM
Tom Linden wrote:
> On Fri, 08 Sep 2006 03:33:22 -0700, Peter Flass <Peter_Flass@Yahoo.com>  
> wrote:
> 
>> adaworks@sbcglobal.net wrote:
>>
>>>  In many cases,
>>> it is more appropriate to use a case (PL/I select) statement.
>>> However, if the condition does not resolve to a boolean or
>>> a scalar, in most languages, a case statement is not allowed.
>>> For example if we are testing floating-point values, this
>>> generally works better than a case statement.
>>>
>>
>> You're probably aware that the PL/I SELECT is more general even than  
>> that.  You can code the equivalent of IF..THEN..ELSEI as follows:
>>
>>    SELECT; /* Notice no <expression> on SELECT */
>>      WHEN(first_condition) DO;
>>        ...
>>        END;
>>      WHEN(second_condition) DO;
>>        ...
>>        END;
>>
>> where the xxx_condition can be anything.  The condition expression is  
>> evaluated and converted to a BIT(1) if necessary.  If TRUE (i.e. 
>> '1'b),  the statements in the corresponding DO ... END group are 
>> executed and  the rest of the SELECT is skipped.
>>
> 
> Or, just to complete the picture using label array
> 
> go to case(i);
> 
> case(1): do;
>          end;
> case(2): do;
>          end;
> .
> .
> .
> case(*): do;  /* Equivalent tgo otherwise or default */
>          end;
> 
> 
Where did you get case(*)?  No compiler that I know of allows this. What is its 
exact semantics?

Also, each of the do; .. end; groups should end with a goto to a label just 
after the otherwise.  Finally, the array case should be static or else it will 
be initialized each time execution enters the block in which it is contained.

select(i);
  when(1) do; ... end;
  when(2) do; ... end;
  when(4,7) do; ... end;
  when(5) do; ... end;
  ...
  otherwise do; ... end;
  end;

will generate essentially the same code, i.e., a jump table.  Note also, that 3 
and 6  and all other unused values will jump to the otherwise.  Moroever it is 
unnecessary for the programmer to remember to put in the jumps to the end.  Also 
it deals with values of i <=0 and greater than the largest case without the need 
to enable subscriptrange and provide an on-unit.  All in all a superior approach.
0
jjw (608)
9/8/2006 8:40:55 PM
henrik.sorensen@balcab.ch wrote:
> Shmuel (Seymour J.) Metz wrote:
> 
> 
>>In <1f44e$45011e63$5448c618$12330@news.hispeed.ch>, on 09/08/2006
>>   at 09:41 AM, henrik.sorensen@balcab.ch said:
>>
>>
>>>if condition-1 then
>>> do;
>>>   procedure-1
>>>   procedure-2
>>> end;
>>>else if condition-2 then
>>> do;
>>>   procedure-2
>>>   procedure-3
>>> end;
>>>else if condition-2 then
>>> do;
>>>   procedure-3
>>>   procedure-4
>>>   procedure-5
>>> end;
>>
>>In PL/I (F), yes; not in any current PL/I. 
> 
> to the best of my knowledge, IF ... THEN ... ; ELSE IF ... is still part of
> PL/I, even to most recent versions :-)
> 
I think what he means is that PL/I-F didn't have SELECT.
0
jjw (608)
9/8/2006 8:45:10 PM
adaworks@sbcglobal.net wrote:
> <henrik.sorensen@balcab.ch> wrote in message 
> news:1f44e$45011e63$5448c618$12330@news.hispeed.ch...
> 
>>adaworks@sbcglobal.net wrote:
>>
>>
>>>"Tim C." <tim.challenger@aon.at> wrote in message
>>>news:co20g2tl59fartqh4u4n1o39f1k1fkjego@4ax.com...
>>>
>>>>Following up to <adaworks@sbcglobal.net> :
>>>>
>>>>
>>>>>As I see it, the elsif or elseif,
>>>>>improves readability of code.
>>>>
>>>>I disagree totally.
>>>>--
>>>
>>>How would you code the following?
>>>
>>>if  condition-1 then
>>>               procedure-1;
>>>               procedure-2;
>>>   elsif  condition-2 then
>>>              procedure-2;
>>>              procedure-3;
>>>   elsif condition-3 then
>>>              procedure-3;
>>>              procedure-4;
>>>   else      procedure-5;
>>>end if;
>>
>>if condition-1 then
>> do;
>>   procedure-1
>>   procedure-2
>> end;
>>else if condition-2 then
>> do;
>>   procedure-2
>>   procedure-3
>> end;
>>else if condition-2 then
>> do;
>>   procedure-3
>>   procedure-4
>>   procedure-5
>> end;
>>
>>I dont see the need for a elseif either. It seems pointless to define a new
>>keyword just to save a space.
>>
> 
> Actually, your example is not quite the same.  The elsif is a true multi-way 
> statement,
> similar to a case/select/switch statement, but with an if.   It is not simply a 
> way of
> saving space.

In what way does the semantics of

if e1 then u1; else if e2 then u2;

differ from

if e1 then u1; elseif e2 then u2;

The blank character between else and if is the space that is being "saved"
0
jjw (608)
9/8/2006 8:52:11 PM
"glen herrmannsfeldt" <gah@seniti.ugcs.caltech.edu> wrote in message 
news:eds73m$5cl$3@naig.caltech.edu...
> adaworks@sbcglobal.net wrote:
>
>> Those charged with updating Fortran over the last several versions
>> seem to have had a different opinion since they saw the value of
>> adding an End If to the conditional construct.
>
> Yes, but they didn't remove the non-block IF.
>
True.  However, that construct is deprecated and retained
only to preserve compatibility with older Fortran versions.

Richard 


0
adaworks2 (748)
9/9/2006 12:27:01 AM
On Fri, 08 Sep 2006 13:40:55 -0700, James J. Weinkam <jjw@cs.sfu.ca> wro=
te:

> Tom Linden wrote:
>> On Fri, 08 Sep 2006 03:33:22 -0700, Peter Flass  =

>> <Peter_Flass@Yahoo.com>  wrote:
>>
>>> adaworks@sbcglobal.net wrote:
>>>
>>>>  In many cases,
>>>> it is more appropriate to use a case (PL/I select) statement.
>>>> However, if the condition does not resolve to a boolean or
>>>> a scalar, in most languages, a case statement is not allowed.
>>>> For example if we are testing floating-point values, this
>>>> generally works better than a case statement.
>>>>
>>>
>>> You're probably aware that the PL/I SELECT is more general even than=
   =

>>> that.  You can code the equivalent of IF..THEN..ELSEI as follows:
>>>
>>>    SELECT; /* Notice no <expression> on SELECT */
>>>      WHEN(first_condition) DO;
>>>        ...
>>>        END;
>>>      WHEN(second_condition) DO;
>>>        ...
>>>        END;
>>>
>>> where the xxx_condition can be anything.  The condition expression i=
s   =

>>> evaluated and converted to a BIT(1) if necessary.  If TRUE (i.e.  =

>>> '1'b),  the statements in the corresponding DO ... END group are  =

>>> executed and  the rest of the SELECT is skipped.
>>>
>>  Or, just to complete the picture using label array
>>  go to case(i);
>>  case(1): do;
>>          end;
>> case(2): do;
>>          end;
>> .
>> .
>> .
>> case(*): do;  /* Equivalent tgo otherwise or default */
>>          end;
>>
> Where did you get case(*)?  No compiler that I know of allows this. Wh=
at  =

> is its exact semantics?

Our compilers have done this for 20 years as has Stratus.
>
> Also, each of the do; .. end; groups should end with a goto to a label=
  =

> just after the otherwise.  Finally, the array case should be static or=
  =

> else it will be initialized each time execution enters the block in  =

> which it is contained.

Sorry, quite right a go to out of each do - end group is indeed needed.
This example is actually one we use, as some phases of our compiler are
implemented as table driven interpreters of a stack machine. so that the=

actions are the label do -end blocks and out of which the equivalent of
what you might think of as a program counter is incremented according
to the number of arguments, and this is done at the termninus of the got=
o
>
> select(i);
>   when(1) do; ... end;
>   when(2) do; ... end;
>   when(4,7) do; ... end;
>   when(5) do; ... end;
>   ...
>   otherwise do; ... end;
>   end;
>
> will generate essentially the same code, i.e., a jump table.  Note als=
o,  =

> that 3 and 6  and all other unused values will jump to the otherwise. =
  =

> Moroever it is unnecessary for the programmer to remember to put in th=
e  =

> jumps to the end.  Also it deals with values of i <=3D0 and greater th=
an  =

> the largest case without the need to enable subscriptrange and provide=
  =

> an on-unit.  All in all a superior approach.



-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/9/2006 12:48:00 AM
Peter Flass wrote in message ...
>adaworks@sbcglobal.net wrote:
>> Also,
>> it is no always clear from a language reference manual
>> just what will really happen in a deployed implementation
>> of a compiler.
>
>Having done this not too long ago, I thought both the manuals and the
>grammar were unambiguous.  The one thing I initially overlooked was the
>need to possibly terminate multiple conditionals at the end of a
>BEGIN-block or DO-group, thusly:
>
>    DO i=1 to 5;
>      IF a=1
>         THEN IF b=2
>              THEN ...
>      END;
>
>Where the END statement terminates all the IF-statements and the DO-group.

No, the END statement does not terminate an IF statement.

The IF statement terminates itself, by reason of the appearance of a
statement that is not part of an IF statement.

There is nothing special about an END statement here.
ANY kind of statement (assignment, I/O, CALL, etc) will
result in the IF statement terminating prior.


0
robin_v (2737)
9/9/2006 1:06:45 AM
glen herrmannsfeldt wrote in message ...
>adaworks@sbcglobal.net wrote:
>
>> So, it appears that in PL/I, as in C and Pascal, the
>> DO...END brackets are required to avoid ambiguity.
>> No problem. I just wanted to clear this up in my
>> own mind.
>
>Well, the other way is that PL/I, C, and Pascal resolve
>the ambiguity in the language definition,

There is no ambiguity in the language definition.


0
robin_v (2737)
9/9/2006 1:06:45 AM
adaworks@sbcglobal.net wrote in message ...
>
>"robin" <robin_v@bigpond.com> wrote in message
>news:WzWLg.24937$rP1.8043@news-server.bigpond.net.au...
>>
>> As for Fortran, there was nothing to "correct".  Fortran conditionals
>> were never ambiguous.
>> The basic ones were     IF (AE) s1, s2, s3
>> and       IF (logical expr) stmt
>>
>> A Block IF statement was added to Fortran - IF ELSE END IF.
>>
>Those charged with updating Fortran over the last several versions
>seem to have had a different opinion

Different opinion from what?

> since they saw the value of
>adding an End If to the conditional construct.

The Block IF statement was added to only one version of
Fortran, and was not changed thereafter.

>Many PL/I programmers also seem to see the value of bracketing
>a multiple statement IF construct with a DO ... BEGIN.

I'm not sure what you are saying here.
When more than one executable statement is to be optionally
executed, a DO-group (or, rarely, BEGIN block) must be used.

[OK, the IF can be repeated for each executable statement,
but that would be perverse]


0
robin_v (2737)
9/9/2006 1:06:46 AM
adaworks@sbcglobal.net wrote in message ...
>
>"robin" <robin_v@bigpond.com> wrote in message
>news:WzWLg.24936$rP1.12157@news-server.bigpond.net.au...
>>
>> Some of the things that can be done in PL/I include the following
>> (each is an example of a valid PL/I source statement):
>>
>> Examples:
>> get (B);    Read a matrix, [this statement also reads in the dimensions of the
>> matrix)
>> put (B);    Print a matrix.
>> A = N identity;  Generate a unit matrix of order N, and assign it to A.
>> A = B transpose; Transpose matrix B, and assign it to matrix A.
>> X = B solve;  Solve the equations stored in B, storing the solutions in X.
>> A = B x C;  Matrix multiplication of B and C.
>> A = B invert;  Invert matrix B, and assign the result to matrix A.
>> A = B attach C;  Columns of B are followed by columns of C and are assigned to
>> A.
>> A = B attach_rows C; Rows of B are followed by rows of C, and are assigned to
>> A.
>> A = B sin;  The sine of B is assigned to A.
>>
>Good examples.  However, they are not unique to PL/I.

In which other languages do you find this kind of construct?


0
robin_v (2737)
9/9/2006 1:06:47 AM
henrik.sorensen@balcab.ch wrote:
> adaworks@sbcglobal.net wrote:
> 
>> "Tim C." <tim.challenger@aon.at> wrote in message
>> news:co20g2tl59fartqh4u4n1o39f1k1fkjego@4ax.com...
>>> Following up to <adaworks@sbcglobal.net> :
>>>
>>>> As I see it, the elsif or elseif,
>>>> improves readability of code.
>>> I disagree totally.
>>> --
>> How would you code the following?
>>
>> if  condition-1 then
>>                procedure-1;
>>                procedure-2;
>>    elsif  condition-2 then
>>               procedure-2;
>>               procedure-3;
>>    elsif condition-3 then
>>               procedure-3;
>>               procedure-4;
>>    else      procedure-5;
>> end if;
> 
> if condition-1 then 
>   do;
>     procedure-1
>     procedure-2
>   end;
> else if condition-2 then
>   do;
>     procedure-2
>     procedure-3
>   end;
> else if condition-2 then
>   do;
>     procedure-3
>     procedure-4
>     procedure-5
>   end;
> 
> I dont see the need for a elseif either. It seems pointless to define a new
> keyword just to save a space.

It isn't just to save a space, it's a clue for human readers and for 
prettyprinters, to distinguish

   if a then
      do_a
   else
      if b then
         do_b
      else
         if c then
            do_c
         else
            do_d

from

    if a then
       do_a
    elseif b then
       do_b
    elseif c then
       do_c
    else
       do_d

PL/I has a way of doing this without adding elseif

    select;
       when (a)
          do_a
       when (b)
          do_b
       when (c)
          do_c
       otherwise
          do_d
     end;

The general trend of language design, however, has been to use elseif 
(also frequently spelled elsif or elif). The "select (x)" form, however, 
has an analog in most modern languages.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
9/9/2006 2:55:56 AM
adaworks@sbcglobal.net wrote:

(snip regarding IF statements)

>>Yes, but they didn't remove the non-block IF.

> True.  However, that construct is deprecated and retained
> only to preserve compatibility with older Fortran versions.

As far as I can tell from the last draft of Fortran 2003 the IF
statement (not the IF construct) is not obsolescent.  (That is the
term they use, instead of deprecated.)

If it was obsolescent it could be considered for deletion, but not
while it is still widely used.  It probably has to be obsolescent for
a while before it is obsolete, and actually considered for deletion.

It will then be some years before compilers even support the new
version, and most will still support obsolete features for years
to come.  Consider that Fortran 77 compilers are still being
worked on.

-- glen

0
gah (12851)
9/9/2006 4:44:38 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:GsoMg.25715$rP1.6072@news-server.bigpond.net.au...
>
> When more than one executable statement is to be optionally
> executed, a DO-group (or, rarely, BEGIN block) must be used.
>
Thank you.  This conforms to what I was saying earlier
about the value of an end-if for an if.   The syntax, in
languages that require this is,

        if condition then
           statement-1;
           statement-2;
           statement-n;
        else
           statement-a;
           statement-b;
       end if;

Except for the difference in syntax, I wonder how
this is different from requiring a DO...END?
As I noted earlier, I am not deprecating DO ... END.
We are simply agreeing here that a scope delimiter
of some form has  value in this set of circumstances.

Richard 


0
adaworks2 (748)
9/9/2006 5:01:24 AM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message 
news:53qMg.713$344.286@newsfe12.lga...
>
> PL/I has a way of doing this without adding elseif
>
>    select;
>       when (a)
>          do_a
>       when (b)
>          do_b
>       when (c)
>          do_c
>       otherwise
>          do_d
>     end;
>
> The general trend of language design, however, has been to use elseif (also 
> frequently spelled elsif or elif). The "select (x)" form, however, has an 
> analog in most modern languages.
>
John, good example.  In your example, above,

    1)  can the when(a) be a non-discrete value?
         For example, can it be a floating-point or fixed-point value?

    2)  can when(a)  be a a non-boolean expression?
         can it be an expression that resolves to a discrete
         result?

Thanks,

Richard 


0
adaworks2 (748)
9/9/2006 5:06:18 AM
"Tom Linden" <tom@kednos-remove.com> wrote in message 
news:op.tfk5uak4tte90l@hyrrokkin...
On Fri, 08 Sep 2006 13:40:55 -0700, James J. Weinkam <jjw@cs.sfu.ca> wrote:


> Sorry, quite right a go to out of each do - end group is indeed needed.
> This example is actually one we use, as some phases of our compiler are
> implemented as table driven interpreters of a stack machine. so that the
> actions are the label do -end blocks and out of which the equivalent of what 
> you might think of as a program counter is incremented according
> to the number of arguments, and this is done at the termninus of the goto
>
Am I reading this correctly?   Are you saying that, to exit a do...end
block, one must include a goto statement?   I am sure I must be
misintrepeting your comment.   As you know, modern computer
science has widely deprecated the goto.  A lot of languages don't
have a goto at all.

There are circumstances when, for efficiency purposes, one needs
a goto statement.  However, it is usually considered bad design to
use the goto for anything other than improved performance of a
program.

BTW, I just found out that we have an IBM mainframe chugging
away at our college.  It mainly runs SAS programs, but there is
a PL/I compiler on it.   Further, I think I can get my students logon
authority.

Richard

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ 


0
adaworks2 (748)
9/9/2006 5:17:07 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:HsoMg.25716$rP1.8466@news-server.bigpond.net.au...
> adaworks@sbcglobal.net wrote in message ...
>>
>>"robin" <robin_v@bigpond.com> wrote in message
>>news:WzWLg.24936$rP1.12157@news-server.bigpond.net.au...
>>>
>>> Some of the things that can be done in PL/I include the following
>>> (each is an example of a valid PL/I source statement):
>>>
>>> Examples:
>>> get (B);    Read a matrix, [this statement also reads in the dimensions of 
>>> the
>>> matrix)
>>> put (B);    Print a matrix.
>>> A = N identity;  Generate a unit matrix of order N, and assign it to A.
>>> A = B transpose; Transpose matrix B, and assign it to matrix A.
>>> X = B solve;  Solve the equations stored in B, storing the solutions in X.
>>> A = B x C;  Matrix multiplication of B and C.
>>> A = B invert;  Invert matrix B, and assign the result to matrix A.
>>> A = B attach C;  Columns of B are followed by columns of C and are assigned 
>>> to
>>> A.
>>> A = B attach_rows C; Rows of B are followed by rows of C, and are assigned 
>>> to
>>> A.
>>> A = B sin;  The sine of B is assigned to A.
>>>
>>Good examples.  However, they are not unique to PL/I.
>
> In which other languages do you find this kind of construct?
>
Well, to begin with, MATLAB and Mathematica.

Also, most imperative languages include libraries for very sophisticated
matrix manipulation.   I can even recall doing a lot of these operations
such as matrix inversion, matrix arithmetic of all kinds, and other matrix
operations in a version of BASIC as early as 1969 on an HP 2000A.

Matrix operations are an essential capability for any kind of modern
computing.  It is nice that PL/I includes them as part of the language.
However, they work just as well in languages where they are supplied
as generic library routines.

Further, in a functional languages such as Haskell or ML, this kind of
thing is almost trivial to code for someone who understands the underlying
mathematics.

Richard
> 


0
adaworks2 (748)
9/9/2006 5:24:20 AM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:FemdnTvO6oT325_YnZ2dnUVZ_qWdnZ2d@comcast.com...
>
> It will then be some years before compilers even support the new
> version, and most will still support obsolete features for years
> to come.  Consider that Fortran 77 compilers are still being
> worked on.
>
My Fortran begins way back in the 1960's with FORTRAN II.   We were
still confined to computational IF statements.  I think those are still
available in modern Fortran (now spelled with a lead UC and the
rest in LC).   For me, Fortran 77 was a gigantic breakthrough in
language design.   Although I have not yet used Fortran 2005,
I have studied the language design in some detail, and really
like it.

At our college, Fortran is the dominant language in several of
our academic departments.  We have one of the top meteorological
departments in the world, and most of the meteorologists still
prefer Fortran.   We also have an ocean science department
with students in Master's and PhD programs.  They seem to
like Fortran and MATLAB.

The important thing is that students and researchers choose the
tools that make the most sense for the kinds of problems they
are solving.   Sometimes I am asked to update someone from
another department regarding advances in programming languages,
since that is one of my specialty areas.    If they are already
comfortable with older Fortran, I sometimes suggest they
consider moving to the next level of that language.   Now that
it includes support for OOP, and an improved model for
programming-in-the-large, that seems the right answer.
Also, we have a sister site not far away that can, in the
near future, benefit from MP-Fortran.

Richard 


0
adaworks2 (748)
9/9/2006 5:34:15 AM
Tom Linden wrote:
> On Fri, 08 Sep 2006 13:40:55 -0700, James J. Weinkam <jjw@cs.sfu.ca> wrote:
> 
>> Tom Linden wrote:
>>
>>> On Fri, 08 Sep 2006 03:33:22 -0700, Peter Flass  
>>> <Peter_Flass@Yahoo.com>  wrote:
>>>
>>>> adaworks@sbcglobal.net wrote:
>>>>
>>>>>  In many cases,
>>>>> it is more appropriate to use a case (PL/I select) statement.
>>>>> However, if the condition does not resolve to a boolean or
>>>>> a scalar, in most languages, a case statement is not allowed.
>>>>> For example if we are testing floating-point values, this
>>>>> generally works better than a case statement.
>>>>>
>>>>
>>>> You're probably aware that the PL/I SELECT is more general even 
>>>> than   that.  You can code the equivalent of IF..THEN..ELSEI as 
>>>> follows:
>>>>
>>>>    SELECT; /* Notice no <expression> on SELECT */
>>>>      WHEN(first_condition) DO;
>>>>        ...
>>>>        END;
>>>>      WHEN(second_condition) DO;
>>>>        ...
>>>>        END;
>>>>
>>>> where the xxx_condition can be anything.  The condition expression 
>>>> is   evaluated and converted to a BIT(1) if necessary.  If TRUE 
>>>> (i.e.  '1'b),  the statements in the corresponding DO ... END group 
>>>> are  executed and  the rest of the SELECT is skipped.
>>>>
>>>  Or, just to complete the picture using label array
>>>  go to case(i);
>>>  case(1): do;
>>>          end;
>>> case(2): do;
>>>          end;
>>> .
>>> .
>>> .
>>> case(*): do;  /* Equivalent tgo otherwise or default */
>>>          end;
>>>
>> Where did you get case(*)?  No compiler that I know of allows this. 
>> What  is its exact semantics?
> 
> 
> Our compilers have done this for 20 years as has Stratus.
> 
>>
>> Also, each of the do; .. end; groups should end with a goto to a 
>> label  just after the otherwise.  Finally, the array case should be 
>> static or  else it will be initialized each time execution enters the 
>> block in  which it is contained.
> 
> 
> Sorry, quite right a go to out of each do - end group is indeed needed.

Otherwise you wind up with the (broken, IMHO) semantics of C's switch 
statement.

> This example is actually one we use, as some phases of our compiler are
> implemented as table driven interpreters of a stack machine. so that the
> actions are the label do -end blocks and out of which the equivalent of
> what you might think of as a program counter is incremented according
> to the number of arguments, and this is done at the termninus of the goto
> 
>>
>> select(i);
>>   when(1) do; ... end;
>>   when(2) do; ... end;
>>   when(4,7) do; ... end;
>>   when(5) do; ... end;
>>   ...
>>   otherwise do; ... end;
>>   end;
>>
>> will generate essentially the same code, i.e., a jump table.  Note 
>> also,  that 3 and 6  and all other unused values will jump to the 
>> otherwise.   Moroever it is unnecessary for the programmer to remember 
>> to put in the  jumps to the end.  Also it deals with values of i <=0 
>> and greater than  the largest case without the need to enable 
>> subscriptrange and provide  an on-unit.  All in all a superior approach.
> 

How do you do this?  How do you differentiate this from, e.g.
   SELECT(i);
     WHEN(1) DO; ... END;
     WHEN(600) DO; ... END
     WHEN(1_000_000) DO; ... END;
     END;

Obviously you don't want to generate a 1 million entry jump table.  Do 
you treat the case where all the WHEN expressions are "small" integers 
as a special case?


0
Peter_Flass (956)
9/9/2006 11:46:59 AM
adaworks@sbcglobal.net wrote in message ...
>
>"glen herrmannsfeldt" <gah@seniti.ugcs.caltech.edu> wrote in message
>news:eds73m$5cl$3@naig.caltech.edu...
>> adaworks@sbcglobal.net wrote:
>>
>>> Those charged with updating Fortran over the last several versions
>>> seem to have had a different opinion since they saw the value of
>>> adding an End If to the conditional construct.
>>
>> Yes, but they didn't remove the non-block IF.
>>
>True.  However, that construct is deprecated and retained
>only to preserve compatibility with older Fortran versions.

Whether or not it is deprecated is not relevant.

The fact remains that neither the arithnmetic IF nor the logical IF
was removed nor altered in any way.


0
robin_v (2737)
9/9/2006 2:14:50 PM
From: adaworks@sbcglobal.net <adaworks@sbcglobal.net>
Newsgroups: comp.lang.pl1
Date: Friday, 8 September 2006 15:31

>"robin" <robin_v@bigpond.com> wrote in message
>news:WzWLg.24937$rP1.8043@news-server.bigpond.net.au...
>>
>> As for Fortran, there was nothing to "correct".  Fortran conditionals
>> were never ambiguous.
>> The basic ones were     IF (AE) s1, s2, s3
>> and       IF (logical expr) stmt
>>
>> A Block IF statement was added to Fortran - IF ELSE END IF.
>>
>Those charged with updating Fortran over the last several versions
>seem to have had a different opinion since they saw the value of
>adding an End If to the conditional construct.

No, they didn't add "ENDIF" to the conditional construct.
They introduced a completely new construct (called the BLOCK IF)
with the NEW keywords THEN, ELSE, and END IF.

No existing IF construct was altered, modified, or deleted.
That's still the case today.


0
robin_v (2737)
9/9/2006 2:14:50 PM
"robin" <robin_v@bigpond.com> wrote in message 
news:u%zMg.26154$rP1.5587@news-server.bigpond.net.au...
>
> No, they didn't add "ENDIF" to the conditional construct.
> They introduced a completely new construct (called the BLOCK IF)
> with the NEW keywords THEN, ELSE, and END IF.
>
> No existing IF construct was altered, modified, or deleted.
> That's still the case today.
>
A subtle distinction.  The "block if" was introduced for a reason.
What do suppose that might have been.

The earlier if statements were retained for compatibility across
the earlier versions.   Who, in their right mind, would use a
computational if these days?
>
Richard 


0
adaworks2 (748)
9/9/2006 2:39:25 PM
On Fri, 08 Sep 2006 10:15:54 -0700, <adaworks@sbcglobal.net> wrote:

>
> "Tom Linden" <tom@kednos-remove.com> wrote in message
> news:op.tfj75qr2tte90l@hyrrokkin...
>> On Thu, 07 Sep 2006 22:45:55 -0700, <adaworks@sbcglobal.net> wrote:
>>
>>> Now, it is certainly true that not every programming problem needs to   
>>> be, or
>>> even should be, written using OOP.   Inheritance is often overworked,  
>>> and
>>> even more often misused.   Dynamic polymorphism carries some serious
>>> safety concerns and is inappropriate for embedded safety-critical   
>>> software.
>>> Lots of other popular mechanisms in object-oriented programming,   
>>> especially
>>> in C++, are inherently dangerous.   There is still a role for good
>>> old-fashioned
>>> structured/procedural programming and PL/I can fill a niche in that   
>>> domain.
>>
>> Richard, could you expound on those points?  If it is unsafe in one
>> area, why is it not unsafe in any area.  Encapsulation is another
>> method that has gone to the ridiculous extreme.
>>
> Dynamic binding is based on the idea that each method invocation is
> resolved at the time of execution.   This is an excellent approach to
> programs that can afford to sometimes (rarely, I admit) get it wrong
> or try to invoke a method that does not exist.  Exception handling
> can deal with that nicely.
>
> When combined with polymorphism, this works almost like a dynamic
> case statement.   It is usually built over the inheritance model and
> involves overriding of methods (same name, extended behavior).
> Frequently, it also involves liberal use of pointers and dynamic
> allocation of memory.
>
> In the safety-critical world, where I spent part of my career, and
> still consult from time to time, we demand a high-level of
> predictability.    As the inheritance tree grows larger, it becomes
> more difficult, in a dynamic polymorphism model, to have confidence
> in the level of predictability -- it is harder to prove a program  
> correct.
>
> Consider the example of a very clever piece of software written to
> manage an operating room during surgery.   It had to be rebooted
> from time to time.  Exception-handling can help, but safety-critical
> software does not encourage reliance on this mechanism.
>
> Some OOP environments are emerging, due to improvements in
> language design, that are more amenable to safety-critical software,
> but we still have a way to go before the safety-critical community
> is entirely satisfied.
>
> One advance that is helping a lot is the application of the Hoare
> Triplet.  This is an assertion model overlaid onto the programming
> language.  It is a powerful tool which allows one to build specifications
> into the program for checking key constructs prior to invocation, and at
> completion of processing.   Add to that the invariant assertion and one
> has a very powerful set of tools for improving dependability.
>
> A few languages have good assertion capabilities.  One of the best, at
> this time, is Eiffel.
>
> However, in the safety-critical world, assertions need to be shown to be
> correct, not at run-time, but at development time  -- before deployment.
> This is a very difficult problem, but some of the best and brightest  
> minds
> in the computing industry have been making significant advances in this
> direction over the past ten years.
>
> That last paragraph goes back to the original statement.  In the world of
> safety-critical software, we don't want any chance of an error occurring
> at run-time.   We want to be able to establish the validity of every
> construct through the combination of good design principles, good
> development tools, and good developers.  Any level of unpredictability
> is unacceptable.
>
> We are not yet at the point where we have reached the goal at the level
> anyone would prefer.   However, the current state-of-the-art, over the
> past ten years, has demonstrated remarkable results.  In particular, the
> SPARK approach (which does not permit dynamic binding or dynamic
> polymorphism, but does have limited support for inheritance) has shown
> that we can achieve a lot of our goals.
>
> I hope this helps.  I am certainly willing to answer any other questions
> about this if you are interested.

I guess I am obsolete.  i really see no value in the OOP approach, indeed  
I see
many problems.  You really didn't respond directly to my question on the  
safety
issue.  I really don't care how many advances they make in plugging holes,  
the
basic paradigm, to me, is flawed.  I don't think you can have a safe OOP  
environment
without a model similar to Gnosis, L4 Micro kernel or similar, wherein  
authority is
conveyed upon invocation, but even then you still have the problem of  
mutually suspicious programs.   What OOP proponents have succeded in doing  
is defing  a whole
new bunch  of terms to describe the mess they have created and now they  
have years of
research to show that is (1) useable, and (2) safe to us.  No thanks, I am  
not buying.
>
> Richard
>
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/9/2006 9:37:09 PM
On Sat, 09 Sep 2006 04:46:59 -0700, Peter Flass <Peter_Flass@Yahoo.com> =
 =

wrote:

> Tom Linden wrote:
>> On Fri, 08 Sep 2006 13:40:55 -0700, James J. Weinkam <jjw@cs.sfu.ca> =
 =

>> wrote:
>>
>>> Tom Linden wrote:
>>>
>>>> On Fri, 08 Sep 2006 03:33:22 -0700, Peter Flass   =

>>>> <Peter_Flass@Yahoo.com>  wrote:
>>>>
>>>>> adaworks@sbcglobal.net wrote:
>>>>>
>>>>>>  In many cases,
>>>>>> it is more appropriate to use a case (PL/I select) statement.
>>>>>> However, if the condition does not resolve to a boolean or
>>>>>> a scalar, in most languages, a case statement is not allowed.
>>>>>> For example if we are testing floating-point values, this
>>>>>> generally works better than a case statement.
>>>>>>
>>>>>
>>>>> You're probably aware that the PL/I SELECT is more general even  =

>>>>> than   that.  You can code the equivalent of IF..THEN..ELSEI as  =

>>>>> follows:
>>>>>
>>>>>    SELECT; /* Notice no <expression> on SELECT */
>>>>>      WHEN(first_condition) DO;
>>>>>        ...
>>>>>        END;
>>>>>      WHEN(second_condition) DO;
>>>>>        ...
>>>>>        END;
>>>>>
>>>>> where the xxx_condition can be anything.  The condition expression=
  =

>>>>> is   evaluated and converted to a BIT(1) if necessary.  If TRUE  =

>>>>> (i.e.  '1'b),  the statements in the corresponding DO ... END grou=
p  =

>>>>> are  executed and  the rest of the SELECT is skipped.
>>>>>
>>>>  Or, just to complete the picture using label array
>>>>  go to case(i);
>>>>  case(1): do;
>>>>          end;
>>>> case(2): do;
>>>>          end;
>>>> .
>>>> .
>>>> .
>>>> case(*): do;  /* Equivalent tgo otherwise or default */
>>>>          end;
>>>>
>>> Where did you get case(*)?  No compiler that I know of allows this. =
 =

>>> What  is its exact semantics?
>>   Our compilers have done this for 20 years as has Stratus.
>>
>>>
>>> Also, each of the do; .. end; groups should end with a goto to a  =

>>> label  just after the otherwise.  Finally, the array case should be =
 =

>>> static or  else it will be initialized each time execution enters th=
e  =

>>> block in  which it is contained.
>>   Sorry, quite right a go to out of each do - end group is indeed  =

>> needed.
>
> Otherwise you wind up with the (broken, IMHO) semantics of C's switch =
 =

> statement.
>
>> This example is actually one we use, as some phases of our compiler a=
re
>> implemented as table driven interpreters of a stack machine. so that =
the
>> actions are the label do -end blocks and out of which the equivalent =
of
>> what you might think of as a program counter is incremented according=

>> to the number of arguments, and this is done at the termninus of the =
 =

>> goto
>>
>>>
>>> select(i);
>>>   when(1) do; ... end;
>>>   when(2) do; ... end;
>>>   when(4,7) do; ... end;
>>>   when(5) do; ... end;
>>>   ...
>>>   otherwise do; ... end;
>>>   end;
>>>
>>> will generate essentially the same code, i.e., a jump table.  Note  =

>>> also,  that 3 and 6  and all other unused values will jump to the  =

>>> otherwise.   Moroever it is unnecessary for the programmer to rememb=
er  =

>>> to put in the  jumps to the end.  Also it deals with values of i <=3D=
0  =

>>> and greater than  the largest case without the need to enable  =

>>> subscriptrange and provide  an on-unit.  All in all a superior  =

>>> approach.
>>
>
> How do you do this?  How do you differentiate this from, e.g.
>    SELECT(i);
>      WHEN(1) DO; ... END;
>      WHEN(600) DO; ... END
>      WHEN(1_000_000) DO; ... END;
>      END;
>
> Obviously you don't want to generate a 1 million entry jump table.  Do=
  =

> you treat the case where all the WHEN expressions are "small" integers=
  =

> as a special case?
>
After a number of experiments, I ended up with branch logic rather than
jump table.  Since you can't assume a dense set you need to treat the  =

general
case.  Moreover, the general case involves expressions, which values are=
  =

only
known at runtime.



-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/9/2006 10:00:31 PM
On Fri, 08 Sep 2006 22:06:18 -0700, <adaworks@sbcglobal.net> wrote:

>
> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> news:53qMg.713$344.286@newsfe12.lga...
>>
>> PL/I has a way of doing this without adding elseif
>>
>>    select;
>>       when (a)
>>          do_a
>>       when (b)
>>          do_b
>>       when (c)
>>          do_c
>>       otherwise
>>          do_d
>>     end;
>>
>> The general trend of language design, however, has been to use elseif  
>> (also
>> frequently spelled elsif or elif). The "select (x)" form, however, has  
>> an
>> analog in most modern languages.
>>
> John, good example.  In your example, above,
>
>     1)  can the when(a) be a non-discrete value?
>          For example, can it be a floating-point or fixed-point value?

It can be an expression
>
>     2)  can when(a)  be a a non-boolean expression?
>          can it be an expression that resolves to a discrete
>          result?
>
see  
http://www.kednos.com/pli/docs/REFERENCE_MANUAL/6291pro_022.html#index_x_1071
> Thanks,
>
> Richard
>
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/9/2006 10:03:51 PM
adaworks@sbcglobal.net wrote:
> "Tom Linden" <tom@kednos-remove.com> wrote in message 
> news:op.tfk5uak4tte90l@hyrrokkin...
> On Fri, 08 Sep 2006 13:40:55 -0700, James J. Weinkam <jjw@cs.sfu.ca> wrote:
> 
> 
> 
>>Sorry, quite right a go to out of each do - end group is indeed needed.
>>This example is actually one we use, as some phases of our compiler are
>>implemented as table driven interpreters of a stack machine. so that the
>>actions are the label do -end blocks and out of which the equivalent of what 
>>you might think of as a program counter is incremented according
>>to the number of arguments, and this is done at the termninus of the goto
>>
> 
> Am I reading this correctly?   Are you saying that, to exit a do...end
> block, one must include a goto statement?   I am sure I must be
> misintrepeting your comment.

No, you are not reading it correctly.  When control reaches the end of a do; ... 
end; group it goes to the next executable statement.

However, in the example at hand, a label array, initialized by subscripted label 
prefixes was being used to synthesize a case statement, so the do group that 
implements each arm of the case needs to go to the end of the case statement not 
to the next arm.  For example, consider the Pascal case statement:

  case i of
   1: a1;
   2: a2;
   ...
   n: an
   end

In versions of PL/I that predated the introduction of the SELECT statement, this 
was easily synthesized as follows:

  dcl case(n) label;
  ...
  goto case(i);
  case(1): do; a1; goto endcase; end;
  case(2): do; a2; goto endcase; end;
  ...
  case(n): do; an; end;
  endcase:;

Needless to say, with modern versions of PL/I which include SELECT, one writes:

  select(i);
   when(1) a1;
   when(2) a2;
   ...
   when(n) an;
  {otherwise whatever;}
   end;

Here, if any of the ai required begin ... end in Pascal, do; ... end; would be 
substituted instead unless the begin ... end sequence included declarations.

> There are circumstances when, for efficiency purposes, one needs
> a goto statement.  However, it is usually considered bad design to
> use the goto for anything other than improved performance of a
> program.

I disagree.  The goto is seldom if ever needed for efficiency.  It is needed for 
two purposes:

1.  To synthesize control structures not provided in the host language.  CASE is 
a moot point nowadays in PL/I since SELECT is available, but is is sure useful 
synthesizing finite state machine models when SELECT is inadequate.

2.  To escape from a deeply nested control structure in the case of serious 
error.  This avoids the complexity of having all the intermediate levels having 
to get in on the act.  Knuth's 1974 paper, "Structured Programming with GOTO 
Statements" is still relevant after all these years.
0
jjw (608)
9/9/2006 10:08:28 PM
Peter Flass wrote:
> Tom Linden wrote:
> 
>> On Fri, 08 Sep 2006 13:40:55 -0700, James J. Weinkam <jjw@cs.sfu.ca> 
>> wrote:
>>> select(i);
>>>   when(1) do; ... end;
>>>   when(2) do; ... end;
>>>   when(4,7) do; ... end;
>>>   when(5) do; ... end;
>>>   ...
>>>   otherwise do; ... end;
>>>   end;
>>>
>>> will generate essentially the same code, i.e., a jump table.  Note 
>>> also,  that 3 and 6  and all other unused values will jump to the 
>>> otherwise.   Moroever it is unnecessary for the programmer to 
>>> remember to put in the  jumps to the end.  Also it deals with values 
>>> of i <=0 and greater than  the largest case without the need to 
>>> enable subscriptrange and provide  an on-unit.  All in all a superior 
>>> approach.
>>
>>
> 
> How do you do this?  How do you differentiate this from, e.g.
>   SELECT(i);
>     WHEN(1) DO; ... END;
>     WHEN(600) DO; ... END
>     WHEN(1_000_000) DO; ... END;
>     END;
> 
> Obviously you don't want to generate a 1 million entry jump table.  Do 
> you treat the case where all the WHEN expressions are "small" integers 
> as a special case?
> 
> 
I don't do it.  I am talking about what IBM's PL/I compilers do.

Needless to say the compiler conmputes the density of the nontrivial entries 
that would occur in the jump table and if it is too low reverts to the 
equivalent of the

if c1 then a1;
else if c2 then a2;
....

model.

I have no idea how it chooses the crossover point but in all the cases I have 
actually looked at it does a fine job.  It also does a good job of loop unrolling.

So that you can see for yourself, I just typed in and compiled my example of 
yesterday and your "counterexample" using Personal PL/I for OS/2:


000000df 0f be 85 57 ff ff ff    	movsx	eax,byte ptr [ebp-0a9h]; I
000000e6 83 f8 07                	cmp	eax,07h
000000e9 77 00                   	ja	@BLBL10
000000eb ff 24 85 24 00 00 00    	jmp	dword ptr [eax*04h+@CBE7]
CONST32_RO	segment
	align 04h
@CBE7:
	dd	offset FLAT: @BLBL10
	dd	offset FLAT: @BLBL6
	dd	offset FLAT: @BLBL7
	dd	offset FLAT: @BLBL10
	dd	offset FLAT: @BLBL8
	dd	offset FLAT: @BLBL9
	dd	offset FLAT: @BLBL10
	dd	offset FLAT: @BLBL8
CONST32_RO	ends
                                   	align 010h
                                   @BLBL6:

; 9   select(i);
; 10    when(1) j=23;
000000f2 8d 40 16                	lea	eax,[eax+016h]
000000f5 eb 00                   	jmp	@BLBL5
                                   	align 010h
                                   @BLBL7:

; 11    when(2) j=31;
000000f7 8d 40 1d                	lea	eax,[eax+01dh]
000000fa eb 00                   	jmp	@BLBL5
000000fc 8b c0 8b c0             	align 010h
                                   @BLBL8:

; 12    when(4,7) j=43;
00000100 b8 2b 00 00 00          	mov	eax,02bh
00000105 eb 00                   	jmp	@BLBL5
                                   	align 010h
                                   @BLBL9:

; 13    when(5) j=56;
00000107 8d 40 33                	lea	eax,[eax+033h]
0000010a eb 00                   	jmp	@BLBL5
                                   	align 010h
                                   @BLBL10:

; 14    otherwise j=-1;
0000010c 83 c8 ff                	or	eax,0ffffffffh
                                   @BLBL5:
0000010f 89 85 58 ff ff ff       	mov	[ebp-0a8h],eax;	J

; 15    end;

Observe that the optimizer discovered that each arm of the select culminated in 
an assignment to j and so moved that to the end saving space (but not time). 
Also when possible it came up with the required value in eax by building on what 
was already known to be there when possible, saving code space and execution time.


000000df 8b 85 60 ff ff ff       	mov	eax,[ebp-0a0h];	I
000000e5 83 f8 01                	cmp	eax,01h
000000e8 74 00                   	je	@BLBL6
000000ea 3d 58 02 00 00          	cmp	eax,0258h
000000ef 74 00                   	je	@BLBL7
000000f1 3d 40 42 0f 00          	cmp	eax,0f4240h
000000f6 74 00                   	je	@BLBL8
000000f8 eb 00                   	jmp	@BLBL9
000000fa 8d 80 00 00 00 00       	align 010h
                                   @BLBL6:

; 9   select(i);
; 10    when(1) j=23;
00000100 b8 17 00 00 00          	mov	eax,017h
00000105 eb 00                   	jmp	@BLBL5
                                   	align 010h
                                   @BLBL7:

; 11    when(600) j=31;
00000107 b8 1f 00 00 00          	mov	eax,01fh
0000010c eb 00                   	jmp	@BLBL5
0000010e 8b c0                   	align 010h
                                   @BLBL8:

; 12    when(1000000) j=43;
00000110 b8 2b 00 00 00          	mov	eax,02bh
00000115 eb 00                   	jmp	@BLBL5
                                   	align 010h
                                   @BLBL9:

; 13    otherwise j=-1;
00000117 83 c8 ff                	or	eax,0ffffffffh
                                   @BLBL5:
0000011a 89 85 54 ff ff ff       	mov	[ebp-0ach],eax;	J

; 14    end;


This time the jump table is replaced by a sequence of if's.  Notice that no 
actual jump occurs until the successful value is reached, minimizing pipeline 
stalls.

I would say, not bad.
0
jjw (608)
9/9/2006 10:40:49 PM
adaworks@sbcglobal.net wrote in message ...
>
>"robin" <robin_v@bigpond.com> wrote in message
>news:GsoMg.25715$rP1.6072@news-server.bigpond.net.au...
>>
>> When more than one executable statement is to be optionally
>> executed, a DO-group (or, rarely, BEGIN block) must be used.
>>
>Thank you.  This conforms to what I was saying earlier
>about the value of an end-if for an if.

It doesn't confirm anything of the sort.
It confirms that PL/I does not need an ENDIF.

>   The syntax, in
>languages that require this is,
>
>        if condition then
>           statement-1;
>           statement-2;
>           statement-n;
>        else
>           statement-a;
>           statement-b;
>       end if;

I'm well aware of that form.  Something quite similar has been used
in FORTRAN since 1977.


0
robin_v (2737)
9/9/2006 10:58:24 PM
adaworks@sbcglobal.net wrote in message <8esMg.23968$kO3.10831@newssvr12.news.prodigy.com>...
>
>"robin" <robin_v@bigpond.com> wrote in message
>news:HsoMg.25716$rP1.8466@news-server.bigpond.net.au...
>> adaworks@sbcglobal.net wrote in message ...
>>>
>>>"robin" <robin_v@bigpond.com> wrote in message
>>>news:WzWLg.24936$rP1.12157@news-server.bigpond.net.au...
>>>>
>>>> Some of the things that can be done in PL/I include the following
>>>> (each is an example of a valid PL/I source statement):
>>>>
>>>> Examples:
>>>> get (B);    Read a matrix, [this statement also reads in the dimensions of
>>>> the
>>>> matrix)
>>>> put (B);    Print a matrix.
>>>> A = N identity;  Generate a unit matrix of order N, and assign it to A.
>>>> A = B transpose; Transpose matrix B, and assign it to matrix A.
>>>> X = B solve;  Solve the equations stored in B, storing the solutions in X.
>>>> A = B x C;  Matrix multiplication of B and C.
>>>> A = B invert;  Invert matrix B, and assign the result to matrix A.
>>>> A = B attach C;  Columns of B are followed by columns of C and are assigned
>>>> to
>>>> A.
>>>> A = B attach_rows C; Rows of B are followed by rows of C, and are assigned
>>>> to
>>>> A.
>>>> A = B sin;  The sine of B is assigned to A.
>>>>
>>>Good examples.  However, they are not unique to PL/I.
>>
>> In which other languages do you find this kind of construct?
>>
>Well, to begin with, MATLAB and Mathematica.

I doubt it.
The above PL/I code has been added to the syntax,
courtesy of the preprocessor, and thus is an enhancement.

>Also, most imperative languages include libraries for very sophisticated
>matrix manipulation.   I can even recall doing a lot of these operations
>such as matrix inversion, matrix arithmetic of all kinds, and other matrix
>operations in a version of BASIC as early as 1969 on an HP 2000A.

Such matrix operations have been done since at least 1955.

>Matrix operations are an essential capability for any kind of modern
>computing.  It is nice that PL/I includes them as part of the language.

PL/I has had array operations since 1966.


0
robin_v (2737)
9/9/2006 10:58:25 PM
adaworks@sbcglobal.net wrote in message ...
>
>"Tom Linden" <tom@kednos-remove.com> wrote in message
>news:op.tfk5uak4tte90l@hyrrokkin...
>On Fri, 08 Sep 2006 13:40:55 -0700, James J. Weinkam <jjw@cs.sfu.ca> wrote:
>
>
>> Sorry, quite right a go to out of each do - end group is indeed needed.
>> This example is actually one we use, as some phases of our compiler are
>> implemented as table driven interpreters of a stack machine. so that the
>> actions are the label do -end blocks and out of which the equivalent of what
>> you might think of as a program counter is incremented according
>> to the number of arguments, and this is done at the termninus of the goto
>>
>Am I reading this correctly?   Are you saying that, to exit a do...end
>block, one must include a goto statement?

No.

>   I am sure I must be
>misintrepeting your comment.   As you know, modern computer
>science has widely deprecated the goto.  A lot of languages don't
>have a goto at all.

The example given uses an old form of computed goto,
or switch.

These days, one uses the structured form provided by a SELECT statement.


0
robin_v (2737)
9/10/2006 12:22:55 AM
Tom Linden wrote in message ...
On Sat, 09 Sep 2006 04:46:59 -0700, Peter Flass <Peter_Flass@Yahoo.com>
wrote:

>> How do you do this?  How do you differentiate this from, e.g.
>>    SELECT(i);
>>      WHEN(1) DO; ... END;
>>      WHEN(600) DO; ... END
>>      WHEN(1_000_000) DO; ... END;
>>      END;
>
>> Obviously you don't want to generate a 1 million entry jump table.  Do
>> you treat the case where all the WHEN expressions are "small" integers
>> as a special case?

>After a number of experiments, I ended up with branch logic rather than
>jump table.  Since you can't assume a dense set you need to treat the
>general case.  Moreover, the general case involves expressions,
>which values are only known at runtime.

But in specific cases where a finite dense list of constants is
available, surely a jump table can be used?


0
robin_v (2737)
9/10/2006 12:22:55 AM
adaworks@sbcglobal.net wrote in message ...
>
>"robin" <robin_v@bigpond.com> wrote in message
>news:u%zMg.26154$rP1.5587@news-server.bigpond.net.au...
>>
>> No, they didn't add "ENDIF" to the conditional construct.
>> They introduced a completely new construct (called the BLOCK IF)
>> with the NEW keywords THEN, ELSE, and END IF.
>>
>> No existing IF construct was altered, modified, or deleted.
>> That's still the case today.
>>
>A subtle distinction.  The "block if" was introduced for a reason.
>What do suppose that might have been.

Not for the reason that you gave.

>The earlier if statements were retained for compatibility across
>the earlier versions.   Who, in their right mind, would use a
>computational if these days?

Hopefully, no one.  (And BTW, it's called ann Arithmetic IF.)


0
robin_v (2737)
9/10/2006 12:22:56 AM
On Sat, 09 Sep 2006 17:22:55 -0700, robin <robin_v@bigpond.com> wrote:

> Tom Linden wrote in message ...
> On Sat, 09 Sep 2006 04:46:59 -0700, Peter Flass <Peter_Flass@Yahoo.com>
> wrote:
>
>>> How do you do this?  How do you differentiate this from, e.g.
>>>    SELECT(i);
>>>      WHEN(1) DO; ... END;
>>>      WHEN(600) DO; ... END
>>>      WHEN(1_000_000) DO; ... END;
>>>      END;
>>
>>> Obviously you don't want to generate a 1 million entry jump table.  Do
>>> you treat the case where all the WHEN expressions are "small" integers
>>> as a special case?
>
>> After a number of experiments, I ended up with branch logic rather than
>> jump table.  Since you can't assume a dense set you need to treat the
>> general case.  Moreover, the general case involves expressions,
>> which values are only known at runtime.
>
> But in specific cases where a finite dense list of constants is
> available, surely a jump table can be used?

Sure, I just didn't find it was worth the effort to special-case.
I mean where do you stop?  You could in that event also you a binary search
to locate the target.
>
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/10/2006 12:27:12 AM
adaworks@sbcglobal.net wrote:
> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message 
> news:53qMg.713$344.286@newsfe12.lga...
>> PL/I has a way of doing this without adding elseif
>>
>>    select;
>>       when (a)
>>          do_a
>>       when (b)
>>          do_b
>>       when (c)
>>          do_c
>>       otherwise
>>          do_d
>>     end;
>>
>> The general trend of language design, however, has been to use elseif (also 
>> frequently spelled elsif or elif). The "select (x)" form, however, has an 
>> analog in most modern languages.
>>
> John, good example.  In your example, above,
> 
>     1)  can the when(a) be a non-discrete value?
>          For example, can it be a floating-point or fixed-point value?
> 
>     2)  can when(a)  be a a non-boolean expression?
>          can it be an expression that resolves to a discrete
>          result?

There are two different SELECT statements. In the first, SELECT itself 
has no argument, and the WHENs are boolean (or compatible) expressions. 
This is essentially equivalent to ELSIF. In the second, SELECT /does/ 
have an argument, and the WHENS are of a type compatible with it. Yes, 
they can be non-discrete, though this is obviously a bad idea in nearly 
all cases. A basic design philosophy of PL/I, now generally regarded as 
having been naive, was, "If it's syntactically valid, and has a 
reasonably clear meaning, make it semantically valid, too." A good many 
limitations in FORTRAN had been to simplify the compiler; this rule was 
in reaction to that. In turn, a good many facets of Ada are in reaction 
to PL/I's excessive freeness.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
9/10/2006 2:44:29 AM
adaworks@sbcglobal.net wrote:
> There are circumstances when, for efficiency purposes, one needs
> a goto statement.  However, it is usually considered bad design to
> use the goto for anything other than improved performance of a
> program.

Ada's goto statement is, I believe, justified not by performance, but by 
the (anticipated) needs of program generators.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
9/10/2006 2:46:34 AM
adaworks@sbcglobal.net wrote:
> "robin" <robin_v@bigpond.com> wrote in message 
> news:GsoMg.25715$rP1.6072@news-server.bigpond.net.au...
>> When more than one executable statement is to be optionally
>> executed, a DO-group (or, rarely, BEGIN block) must be used.
>>
> Thank you.  This conforms to what I was saying earlier
> about the value of an end-if for an if.   The syntax, in
> languages that require this is,
> 
>         if condition then
>            statement-1;
>            statement-2;
>            statement-n;
>         else
>            statement-a;
>            statement-b;
>        end if;
> 
> Except for the difference in syntax, I wonder how
> this is different from requiring a DO...END?
> As I noted earlier, I am not deprecating DO ... END.
> We are simply agreeing here that a scope delimiter
> of some form has  value in this set of circumstances.

The difference is simply that the DO ... END construction was invented 
first (in ALGOL, back in 1959 or so), and the IF ... ENDIF later. They 
are equivalent, but the newer form is preferable -- however, it is not 
so preferable as to justify breaking existing languages

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
9/10/2006 2:50:11 AM
Tom Linden wrote:
(snip)

> I guess I am obsolete.  i really see no value in the OOP approach, 
> indeed  I see many problems.  You really didn't respond
 > directly to my question on the  safety issue.  I really don't
 > care how many advances they make in plugging  holes,  the
> basic paradigm, to me, is flawed.  
(snip)

I wouldn't go quite that far, but I do believe it is overused.

Especially in software where performance is important, excessive
object creation/deletion can be slow, and in many cases it doesn't
really make it more readable.

-- glen

0
gah (12851)
9/10/2006 4:29:02 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:AVIMg.26316$rP1.9306@news-server.bigpond.net.au...
> adaworks@sbcglobal.net wrote in message ...
>>
>>>
>>A subtle distinction.  The "block if" was introduced for a reason.
>>What do suppose that might have been.
>
> Not for the reason that you gave.
>
I cannot help but wonder what you might think the reason
was.

>>The earlier if statements were retained for compatibility across
>>the earlier versions.   Who, in their right mind, would use a
>>computational if these days?
>
> Hopefully, no one.  (And BTW, it's called ann Arithmetic IF.)
>
Well, thank you for that.  Also, the distinction in nomenclature
"arithmetic" versus "computational" is unnecessary.   I have not
programmed a "computational" if in about thirty-five + years, but
I recall quite clearly how it works, having coded more than a
few of them during my Fortran years.

Further.  It seems to me that DO...END within a multiple statement
IF construct,   and IF .... END IF solve the same problem.    In the
C family of languages, it is dealt with through the curly-braces.  In
Pascal, it is with a Begin ... End construct.   The fact is that some
mechanism is required to delimit the scope of a multiple statement
if construct, if one is to expect a dependable outcome.   As I read
the postings in this forum, I note that PL/I is not immune from the
need for this.   That is not a deprecation of PL/I.  As I noted
earlier, the availability of this feature is a good point, not a bad
point, in favor of the language.

Richard

Richard 


0
adaworks2 (748)
9/10/2006 5:17:36 AM
"Tom Linden" <tom@kednos-remove.com> wrote in message 
news:op.tfmrn7q7tte90l@hyrrokkin...
>
> I guess I am obsolete.  i really see no value in the OOP approach, indeed  I 
> see many problems.  You really didn't respond directly to my question on the 
> safety  issue.  I really don't care how many advances they make in plugging 
> holes,  the  basic paradigm, to me, is flawed.  I don't think you can have a 
> safe OOP  environment

First, you are not obsolete.   Your work continues to be valuable and useful.

At the same time, OOP is not as bad as you seem to think.

The fundamental structure of OOP is a class.   A class is simply a special
kind of type that includes some properties for extensibility, polymorphism,
and dynamic binding.

As with any type, a class has the four basic properties:

            1)  a name
            2)  a set of values
            3)  a set of operations
            4)  a set of rules within each language

In some cases, some properties are optional.   For example, there are
types that are never given an explicit name.

A class is also a special case of an abstract data type (ADT).  An ADT is
a type, defined by a software designer, which binds a set of data to a set
of operations.  This is a strong binding.   In fact, it is so strong that the
type and its operations are usually enclosed in some special unit.

        type Machine is
             private:
                    Is_On : Boolean;
             public:
                    Turn_On();
                    Turn_Off();
                    Is_On():Boolean;
        end Machine;

Ideally, the implementation of the Machine operations can be
deferred to a separate compilation unit.   In Java, the implementation
is in-line, which I consider a bad idea, but it works OK for small
programs.

In the type Machine, above, an OOP will use the word "class" instead
of type.   The accessiblity words, private and public, help to protect the
data from being corrupted since it is not global.  In fact, OOP works
hard at eliminating as much global data as possible.

Machine can now be extended with new operations and new attributes
(what OOP calls the data).   The idea is to be able to extend Machine
without breaking any of the existing definition.

        type Rotating_Machine extends Machine is
             private:
                  RPM : Integer;
             public:
                   Turn_On();
                   Turn_Off();
                   Set_RPM(Integer);
                   RPM_Is():Integer;
        end Rotating_Machine;

Yes, I know this is a simple-minded example.   However, some of the
important points are in the example.

            1) Rotating_Machine inherits the data and operations
                of its base type, Machine,
            2) Rotating_Machine has two pieces of data,
                           Is_On
                           RPM
            3) Is_On is private so it is not directly visible to its
                sub-class, Rotating_Machine
            4) The two operations, Turn_On() and Turn_Off()
                are repeated so they can be given their own
                implementation.  That implementation is coded by
                calling the parent operations somewhere.
                Example:
                       Rotating_Machine.Turn_Off() is
                       begin
                            loop
                               decrement RPM to zero
                            end loop
                            Machine.Turn_Off();
                       end Rotating_Machine.Turn_Off();

            5) All data is protected from any corruption by any
                other part of the program.
            6) No operations are allowed on the data except those
                explicitly stated
            7) An instance (sometimes called an object) of Machine
                or Rotating_Machine is just like any other instance of
                a built-in type.   The difference is that it is user-defined.
            8) More and more kinds of Machines can be derived from the
                base type.  This can result in an inheritance tree.   Too deep
                a tree can sometimes, not always, be a bad thing.
            9) The open-closed principle is in-place.   A type/class is open
                to extension, but closed to modification.

The last point is important.  It means that future adaptations need not
do open-heart surgery on the existing code.  No need for new case
statements, if statements, or other tinkering with the existing code.  All
one has to do is design an extension.

There is, of course, much more to OOP than what I have just written.  As
you now, long and tedious books have been written on the subject.

When OOP is appropriate, it is a powerful and valuable approach to
software design.   As noted in an earlier post, it may not always be
appropriate.   However, it is not a method that can be so easily
denounced since it has had and continues to have, a very respectable
body of code that works really well in a large number of environments.

I have stated before that I believe the failure of PL/I to support OOP is
one of its shortcomings.   True believers can object to that all they want,
but until there is a version of PL/I that can satisfy the OOP paradigm, it
will continue to be regarded by a large segment of the programming community
as not being up-to-date.

Programming by extension, a key idea of OOP seems to simply too cumbersome
in PL/I.  Perhaps PL/I experts can satisfy the open-closed principle, but I do
not see it as an easy road for most programmers.

Richard
 


0
adaworks2 (748)
9/10/2006 5:53:53 AM
Tom Linden wrote:
>> How do you do this?  How do you differentiate this from, e.g.
>>    SELECT(i);
>>      WHEN(1) DO; ... END;
>>      WHEN(600) DO; ... END
>>      WHEN(1_000_000) DO; ... END;
>>      END;
>>
>> Obviously you don't want to generate a 1 million entry jump table.  
>> Do  you treat the case where all the WHEN expressions are "small" 
>> integers  as a special case?
>>
> After a number of experiments, I ended up with branch logic rather than
> jump table.  Since you can't assume a dense set you need to treat the  
> general
> case.  Moreover, the general case involves expressions, which values 
> are  only
> known at runtime.
> 

Thanks.  I think it's possinble to optimize aggressively for some 
special cases.  I was wondering if you had found it worthwhile to do 
this, and I'm glad to see I came to the same conclusion you did -- that 
the payoff isn't worth the effort, no matter how tempting it might seem.

My feeling is that if the programmer really *needs* to optimize 
something like this they can use the 'GOTO case(i);' construct.

0
Peter_Flass (956)
9/10/2006 12:47:43 PM
adaworks@sbcglobal.net wrote:
>     1)  can the when(a) be a non-discrete value?
>          For example, can it be a floating-point or fixed-point value?
> 
>     2)  can when(a)  be a a non-boolean expression?
>          can it be an expression that resolves to a discrete
>          result?
> 
I was waiting for John to answer this, but he missed question #2.  Pl/I 
doesn't make the distinction between boolean and computational 
expressions.  The semantics allow any expression, which will be 
converted to a boolean result for the test.  Sometimes the conversion 
rules are a bit baroque, so it's usually best to stick to simple boolean 
expressions such as:
   SELECT;
     WHEN( a<0 ) ...
     WHEN( a=0 ) ...
     OTHERWISE /* a>0 */ ...

0
Peter_Flass (956)
9/10/2006 12:55:49 PM
James J. Weinkam wrote:
> 
> I disagree.  The goto is seldom if ever needed for efficiency.  It is 
> needed for two purposes:
> 
> 1.  To synthesize control structures not provided in the host language.  
> CASE is a moot point nowadays in PL/I since SELECT is available, but is 
> is sure useful synthesizing finite state machine models when SELECT is 
> inadequate.
> 
> 2.  To escape from a deeply nested control structure in the case of 
> serious error.  This avoids the complexity of having all the 
> intermediate levels having to get in on the act.  Knuth's 1974 paper, 
> "Structured Programming with GOTO Statements" is still relevant after 
> all these years.

I'll have to read, or maybe reread, this paper.  The biggest weakness of 
true structured programming with deeply nested structuring is detecting 
some error in the lowest level that should cause current processing to 
abort.  I've been through the process of setting an arror flag and then 
having to test it at each level all the way back up.  It seems to be 
error prone - forget to test in one place and you're chooched.

0
Peter_Flass (956)
9/10/2006 1:01:55 PM
James J. Weinkam wrote:

> Peter Flass wrote:
> 
>> Tom Linden wrote:
>>
>>> On Fri, 08 Sep 2006 13:40:55 -0700, James J. Weinkam <jjw@cs.sfu.ca> 
>>> wrote:
>>>
>>>> select(i);
>>>>   when(1) do; ... end;
>>>>   when(2) do; ... end;
>>>>   when(4,7) do; ... end;
>>>>   when(5) do; ... end;
>>>>   ...
>>>>   otherwise do; ... end;
>>>>   end;
>>>>
>>>> will generate essentially the same code, i.e., a jump table.  Note 
>>>> also,  that 3 and 6  and all other unused values will jump to the 
>>>> otherwise.   Moroever it is unnecessary for the programmer to 
>>>> remember to put in the  jumps to the end.  Also it deals with values 
>>>> of i <=0 and greater than  the largest case without the need to 
>>>> enable subscriptrange and provide  an on-unit.  All in all a 
>>>> superior approach.
>>>
>>>
>>>
>>
>> How do you do this?  How do you differentiate this from, e.g.
>>   SELECT(i);
>>     WHEN(1) DO; ... END;
>>     WHEN(600) DO; ... END
>>     WHEN(1_000_000) DO; ... END;
>>     END;
>>
>> Obviously you don't want to generate a 1 million entry jump table.  Do 
>> you treat the case where all the WHEN expressions are "small" integers 
>> as a special case?
>>
>>
> I don't do it.  I am talking about what IBM's PL/I compilers do.
> 
> Needless to say the compiler conmputes the density of the nontrivial 
> entries that would occur in the jump table and if it is too low reverts 
> to the equivalent of the
> 
> if c1 then a1;
> else if c2 then a2;
> ...
> 
> model.
> 
> I have no idea how it chooses the crossover point but in all the cases I 
> have actually looked at it does a fine job.  It also does a good job of 
> loop unrolling.
> 
> So that you can see for yourself, I just typed in and compiled my 
> example of yesterday and your "counterexample" using Personal PL/I for 
> OS/2:
> 
> 
> 000000df 0f be 85 57 ff ff ff        movsx    eax,byte ptr [ebp-0a9h]; I
> 000000e6 83 f8 07                    cmp    eax,07h
> 000000e9 77 00                       ja    @BLBL10
> 000000eb ff 24 85 24 00 00 00        jmp    dword ptr [eax*04h+@CBE7]
> CONST32_RO    segment
>     align 04h
> @CBE7:
>     dd    offset FLAT: @BLBL10
>     dd    offset FLAT: @BLBL6
>     dd    offset FLAT: @BLBL7
>     dd    offset FLAT: @BLBL10
>     dd    offset FLAT: @BLBL8
>     dd    offset FLAT: @BLBL9
>     dd    offset FLAT: @BLBL10
>     dd    offset FLAT: @BLBL8
> CONST32_RO    ends
>                                       align 010h
>                                   @BLBL6:
> 
> ; 9   select(i);
> ; 10    when(1) j=23;
> 000000f2 8d 40 16                    lea    eax,[eax+016h]
> 000000f5 eb 00                       jmp    @BLBL5
>                                       align 010h
>                                   @BLBL7:
> 
> ; 11    when(2) j=31;
> 000000f7 8d 40 1d                    lea    eax,[eax+01dh]
> 000000fa eb 00                       jmp    @BLBL5
> 000000fc 8b c0 8b c0                 align 010h
>                                   @BLBL8:
> 
> ; 12    when(4,7) j=43;
> 00000100 b8 2b 00 00 00              mov    eax,02bh
> 00000105 eb 00                       jmp    @BLBL5
>                                       align 010h
>                                   @BLBL9:
> 
> ; 13    when(5) j=56;
> 00000107 8d 40 33                    lea    eax,[eax+033h]
> 0000010a eb 00                       jmp    @BLBL5
>                                       align 010h
>                                   @BLBL10:
> 
> ; 14    otherwise j=-1;
> 0000010c 83 c8 ff                    or    eax,0ffffffffh
>                                   @BLBL5:
> 0000010f 89 85 58 ff ff ff           mov    [ebp-0a8h],eax;    J
> 
> ; 15    end;
> 
> Observe that the optimizer discovered that each arm of the select 
> culminated in an assignment to j and so moved that to the end saving 
> space (but not time). Also when possible it came up with the required 
> value in eax by building on what was already known to be there when 
> possible, saving code space and execution time.
> 
> 
> 000000df 8b 85 60 ff ff ff           mov    eax,[ebp-0a0h];    I
> 000000e5 83 f8 01                    cmp    eax,01h
> 000000e8 74 00                       je    @BLBL6
> 000000ea 3d 58 02 00 00              cmp    eax,0258h
> 000000ef 74 00                       je    @BLBL7
> 000000f1 3d 40 42 0f 00              cmp    eax,0f4240h
> 000000f6 74 00                       je    @BLBL8
> 000000f8 eb 00                       jmp    @BLBL9
> 000000fa 8d 80 00 00 00 00           align 010h
>                                   @BLBL6:
> 
> ; 9   select(i);
> ; 10    when(1) j=23;
> 00000100 b8 17 00 00 00              mov    eax,017h
> 00000105 eb 00                       jmp    @BLBL5
>                                       align 010h
>                                   @BLBL7:
> 
> ; 11    when(600) j=31;
> 00000107 b8 1f 00 00 00              mov    eax,01fh
> 0000010c eb 00                       jmp    @BLBL5
> 0000010e 8b c0                       align 010h
>                                   @BLBL8:
> 
> ; 12    when(1000000) j=43;
> 00000110 b8 2b 00 00 00              mov    eax,02bh
> 00000115 eb 00                       jmp    @BLBL5
>                                       align 010h
>                                   @BLBL9:
> 
> ; 13    otherwise j=-1;
> 00000117 83 c8 ff                    or    eax,0ffffffffh
>                                   @BLBL5:
> 0000011a 89 85 54 ff ff ff           mov    [ebp-0ach],eax;    J
> 
> ; 14    end;
> 
> 
> This time the jump table is replaced by a sequence of if's.  Notice that 
> no actual jump occurs until the successful value is reached, minimizing 
> pipeline stalls.
> 
> I would say, not bad.

Agreed.

0
Peter_Flass (956)
9/10/2006 1:04:26 PM
Tom Linden wrote:

> On Sat, 09 Sep 2006 17:22:55 -0700, robin <robin_v@bigpond.com> wrote:
> 
>> Tom Linden wrote in message ...
>> On Sat, 09 Sep 2006 04:46:59 -0700, Peter Flass <Peter_Flass@Yahoo.com>
>> wrote:
>>
>>>> How do you do this?  How do you differentiate this from, e.g.
>>>>    SELECT(i);
>>>>      WHEN(1) DO; ... END;
>>>>      WHEN(600) DO; ... END
>>>>      WHEN(1_000_000) DO; ... END;
>>>>      END;
>>>
>>>
>>>> Obviously you don't want to generate a 1 million entry jump table.  Do
>>>> you treat the case where all the WHEN expressions are "small" integers
>>>> as a special case?
>>
>>
>>> After a number of experiments, I ended up with branch logic rather than
>>> jump table.  Since you can't assume a dense set you need to treat the
>>> general case.  Moreover, the general case involves expressions,
>>> which values are only known at runtime.
>>
>>
>> But in specific cases where a finite dense list of constants is
>> available, surely a jump table can be used?
> 
> 
> Sure, I just didn't find it was worth the effort to special-case.
> I mean where do you stop?  You could in that event also you a binary search
> to locate the target.
> 

Or a hash table ;-)

0
Peter_Flass (956)
9/10/2006 1:06:41 PM
"James J. Weinkam" <jjw@cs.sfu.ca> wrote in message 
news:wXGMg.376$cz3.35@edtnps82...
> adaworks@sbcglobal.net wrote:
>
First, thanks for the clarification.  I was sure I must have misread the
earlier post on this.

>> There are circumstances when, for efficiency purposes, one needs
>> a goto statement.  However, it is usually considered bad design to
>> use the goto for anything other than improved performance of a
>> program.
>
> I disagree.  The goto is seldom if ever needed for efficiency.  It is needed 
> for two purposes:
>
The two examples you cite are correct.  And I am quite familiar
with Knuth's work on this.  The full text is published in his book,
"Literate Programming" and is important for anyone in software.

My comment regarding efficiency is from personal experience.  It was
a once in a lifetime of programming thing.   I doubt I would have to
use this solution again.  However, in that one case, the goto did shave
just enough time from the processing to meet the deadlines.  I can't think
of a time, using a modern programming language, where I have had to
resort to a goto for any other reason.

Richard 


0
adaworks2 (748)
9/10/2006 3:03:45 PM
adaworks@sbcglobal.net wrote:

Firstly, thanks for a really good post.

> Programming by extension, a key idea of OOP seems to simply too cumbersome
> in PL/I.  Perhaps PL/I experts can satisfy the open-closed principle, but I do
> not see it as an easy road for most programmers.

I'm assuming that in the above you meant that it would be difficult to 
do in the current language and pre-processor.

Yes.  I agree.  But not all OOP languages are pure.  There may be some 
advantages to a less than perfect implementation.  At least in limited 
areas.  And using it may require some discipline.

I seem to recall that some people did implementations of some OO stuff 
in C, before C++ and Objective-C became available.  C's (and C++'s too, 
although, with templates there is now more you can do) pre-processor is 
fairly primative, by comparison with what I remember of PL/I's.  If it 
can be done in C, PL/I ought to be far easier.  But this is only what I 
recall.

Personally, I think that function polymorphism might be more difficult, 
eg (in psuedo code):
	integer f(real x) begin ... end;
	integer f(character y) begin ... end;


LR
0
lruss (582)
9/10/2006 5:43:59 PM
Peter Flass wrote:
> Tom Linden wrote:
> 
>>
>> Sure, I just didn't find it was worth the effort to special-case.

Obviously, the implementers of the IBM compilers came to the opposite conclusion.

>> I mean where do you stop?  You could in that event also you a binary 
>> search
>> to locate the target.
>>
> 
> Or a hash table ;-)
> 
No can do. The semantics of SELECT require that the WHEN expressions be 
evaluated in turn until one of them either compares equal to the expression 
following SELECT or contains a 1 bit (if there is no expression following 
SELECT).  At that point evaluation of the expressions stops and the 
corresponding WHEN unit is executed, following which control passes to the next 
executable statement after the SELECT group, unless a goto overrides the 
sequence of control.  Hence SELECT is essentially equivalent to the McCarthy 
sequential conditional.
0
jjw (608)
9/10/2006 6:43:39 PM
LR wrote:
> 
> Personally, I think that function polymorphism might be more difficult, 
> eg (in psuedo code):
>     integer f(real x) begin ... end;
>     integer f(character y) begin ... end;
> 
dcl f generic(fr when(float), fc when(char(*)));
fr: proc(x) returns(bin fixed(31));
  dcl x bin float(53);
  ...
  end fr;

etc.

It's been there since the mid sixties.
0
jjw (608)
9/10/2006 6:54:00 PM
henrik.sorensen@balcab.ch wrote:
> James J. Weinkam wrote:
> 
> 
>>LR wrote:
>>
>>>Personally, I think that function polymorphism might be more difficult,
>>>eg (in psuedo code):
>>>    integer f(real x) begin ... end;
>>>    integer f(character y) begin ... end;
>>>
>>
>>dcl f generic(fr when(float), fc when(char(*)));
>>fr: proc(x) returns(bin fixed(31));
>>  dcl x bin float(53);
>>  ...
>>  end fr;
>>
>>etc.
>>
>>It's been there since the mid sixties.
> 
> you can even have different return values, for different set of parameters. 
> 


Ok, I went back and read the manual.  Looks nice.  I didn't know that 
was part of the language.  Thanks for the correction.

This ought to make doing OOP in PL/I even easier than I thought.

LR
0
lruss (582)
9/10/2006 8:27:28 PM
James J. Weinkam wrote:

> LR wrote:
>> 
>> Personally, I think that function polymorphism might be more difficult,
>> eg (in psuedo code):
>>     integer f(real x) begin ... end;
>>     integer f(character y) begin ... end;
>> 
> dcl f generic(fr when(float), fc when(char(*)));
> fr: proc(x) returns(bin fixed(31));
>   dcl x bin float(53);
>   ...
>   end fr;
> 
> etc.
> 
> It's been there since the mid sixties.
you can even have different return values, for different set of parameters. 

0
9/10/2006 9:01:34 PM
John W. Kennedy wrote in message ...

>There are two different SELECT statements. In the first, SELECT itself
>has no argument, and the WHENs are boolean (or compatible) expressions.
>This is essentially equivalent to ELSIF. In the second, SELECT /does/
>have an argument, and the WHENS are of a type compatible with it. Yes,
>they can be non-discrete, though this is obviously a bad idea in nearly
>all cases. A basic design philosophy of PL/I, now generally regarded as
>having been naive, was, "If it's syntactically valid, and has a
>reasonably clear meaning, make it semantically valid, too." A good many
>limitations in FORTRAN had been to simplify the compiler

and to make life difficult for the programmer,
what with numerous restrictions, etc

>--
>John W. Kennedy


0
robin_v (2737)
9/10/2006 9:57:40 PM
Peter Flass wrote in message ...

>Thanks.  I think it's possinble to optimize aggressively for some
>special cases.  I was wondering if you had found it worthwhile to do
>this, and I'm glad to see I came to the same conclusion you did -- that
>the payoff isn't worth the effort, no matter how tempting it might seem.

There are some cases that invite special casing, including
that when the cases are some letters of the alphabet, or of the digits.
These days, a table of 256 entries is trivial.

>My feeling is that if the programmer really *needs* to optimize
>something like this they can use the 'GOTO case(i);' construct.

The GOTO case construct is not a good one in when there is a
perfectly good alternative (SELECT).


0
robin_v (2737)
9/10/2006 9:57:41 PM
James J. Weinkam wrote in message ...
>Peter Flass wrote:
>> Tom Linden wrote:
>>
>>>
>>> Sure, I just didn't find it was worth the effort to special-case.
>
>Obviously, the implementers of the IBM compilers came to the opposite conclusion.
>
>>> I mean where do you stop?  You could in that event also you a binary
>>> search
>>> to locate the target.
>>>
>>
>> Or a hash table ;-)
>>
>No can do. The semantics of SELECT require that the WHEN expressions be
>evaluated in turn until one of them either compares equal to the expression
>following SELECT or contains a 1 bit (if there is no expression following
>SELECT).

When the WHEN expressions are constants, a fixed table can be used.

>  At that point evaluation of the expressions stops and the
>corresponding WHEN unit is executed, following which control passes to the next
>executable statement after the SELECT group, unless a goto overrides the
>sequence of control.  Hence SELECT is essentially equivalent to the McCarthy
>sequential conditional.


0
robin_v (2737)
9/10/2006 10:39:59 PM
On Sun, 10 Sep 2006 11:43:39 -0700, James J. Weinkam <jjw@cs.sfu.ca> wrote:

> Peter Flass wrote:
>> Tom Linden wrote:
>>
>>>
>>> Sure, I just didn't find it was worth the effort to special-case.
>
> Obviously, the implementers of the IBM compilers came to the opposite  
> conclusion.
>
>>> I mean where do you stop?  You could in that event also you a binary  
>>> search
>>> to locate the target.
>>>
>>  Or a hash table ;-)
>>
> No can do. The semantics of SELECT require that the WHEN expressions be  
> evaluated in turn until one of them either compares equal to the  
> expression following SELECT or contains a 1 bit (if there is no  
> expression following SELECT).  At that point evaluation of the  
> expressions stops and the corresponding WHEN unit is executed, following  
> which control passes to the next executable statement after the SELECT  
> group, unless a goto overrides the sequence of control.  Hence SELECT is  
> essentially equivalent to the McCarthy sequential conditional.

Thank you James, I knew there was  reason i did it that way!


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/10/2006 11:45:30 PM
On Sun, 10 Sep 2006 14:57:41 -0700, robin <robin_v@bigpond.com> wrote:

> Peter Flass wrote in message ...
>
>> Thanks.  I think it's possinble to optimize aggressively for some
>> special cases.  I was wondering if you had found it worthwhile to do
>> this, and I'm glad to see I came to the same conclusion you did -- that
>> the payoff isn't worth the effort, no matter how tempting it might seem.
>
> There are some cases that invite special casing, including
> that when the cases are some letters of the alphabet, or of the digits.
> These days, a table of 256 entries is trivial.
>
>> My feeling is that if the programmer really *needs* to optimize
>> something like this they can use the 'GOTO case(i);' construct.
>
> The GOTO case construct is not a good one in when there is a
> perfectly good alternative (SELECT).
>
I disagree, having generated code for both.



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/10/2006 11:47:10 PM
On Sun, 10 Sep 2006 13:27:28 -0700, LR <lruss@superlink.net> wrote:

> henrik.sorensen@balcab.ch wrote:
>> James J. Weinkam wrote:
>>
>>> LR wrote:
>>>
>>>> Personally, I think that function polymorphism might be more  
>>>> difficult,
>>>> eg (in psuedo code):
>>>>    integer f(real x) begin ... end;
>>>>    integer f(character y) begin ... end;
>>>>
>>>
>>> dcl f generic(fr when(float), fc when(char(*)));
>>> fr: proc(x) returns(bin fixed(31));
>>>  dcl x bin float(53);
>>>  ...
>>>  end fr;
>>>
>>> etc.
>>>
>>> It's been there since the mid sixties.
>>  you can even have different return values, for different set of  
>> parameters.
>
>
> Ok, I went back and read the manual.  Looks nice.  I didn't know that  
> was part of the language.  Thanks for the correction.
>
> This ought to make doing OOP in PL/I even easier than I thought.

OK, what doi you mean by OOP, and why do you think you need it?  What does  
it
bring you that you can't otherwise express?
>
> LR



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/10/2006 11:58:30 PM
Tom Linden wrote:


> OK, what doi you mean by OOP, 

Object oriented programming.


and why do you think you need it?

Need?  Rather want.  I want it because I think it makes writing certain 
kinds of code easier.


> What does  it
> bring you that you can't otherwise express?

Not one thing.  In fact, contrary to what DF says, you can write 
anything in any language that is Turing Complete.  We all might as well 
write code in some portable assembler.

But for the sake of rhetoric I suppose there is some reason most 
programmers write in some higer level language.  Like PL/I or Fortran or 
  even C. I suppose it's that it's easier to be expressive in these 
languages than it is in an assembly language.

OOP features in a language mostly seem to add a huge amount of 
syntactical sugar.  But it's syntactical sugar that let's me get things 
done, but more easily.

I liked Richard's post and example, but I suspect I'm the only one 
posting here who cares about rotating machinery.  Let me try a slightly 
different example.

Suppose for example that we had a store and we sell various kinds of 
things (I'm not worrying about persistence in this example).  Then in 
_pseudo_code_:

class SaleItem {
private:
	Money price_;
public:
	/*	this constructor let's us make a new instance
		of a SaleItem, initializing price_ with the
		value of the parameter 'p'
	*/
	SaleItem(constant Money reference p) : price_(p) { }

	inheritable real taxPercent() { return 0.08; }
	inheritable Money totalPrice() {
		return price_ + price_ * taxPercent();
	}
}

class Candy inherits from SaleItem {
public:
	Candy(constant Money reference p) : SaleItem(p) {}
	/* an instance of Candy will use the taxPercent()
		in SaleItem
	*/
}

class NewsPaper inherits from SaleItem {
public:
	NewsPaper(constant Money reference p) : SaleItem(p) {}

	/* there's no tax on news papers and
		an instance of NewsPaper will use the
		taxPercent() in NewsPaper
	*/
	
	real taxPercent() { return 0.0; }
}

main {
	Candy chocolateBar(0.55);
	write chocolateBar.totalPrice(), " ";
	NewsPaper theSun(1.55);
	write theSun.totalPrice(), newLine;
}

The output will be:
0.594 1.55


Instances of Candy and NewsPaper are going to behave differently.  Can 
this be done without OOP? Sure.  But suppose that we have in our store 
about one hundred different items, each with some slightly different 
behavior.  Can that be done without oop?  Sure.  But I think it would be 
harder.

And suppose, that later I need to add another kind of SaleItem.  It's 
more or less a snap.

There are other advantages too.  If I need to make a copy of some kind 
of SaleItem, without knowing what particular kind it is, in OOP I can do 
that, well, with some limitations.

If I may offer some advice, try to write the above without any oop.  And 
then see how difficult it would be to add another kind of SaleItem, eg 
Beverage, or another kind of behavior to SaleItem, eg requiresBagging().

I hope this clarifies.  It took me sometime to see the whole point of 
the thing, so I can understand why at first or second or third glance 
this might not seem useful.

LR



0
lruss (582)
9/11/2006 1:25:10 AM
James J. Weinkam wrote:
> Peter Flass wrote:
>> Tom Linden wrote:
>>
>>>
>>> Sure, I just didn't find it was worth the effort to special-case.
> 
> Obviously, the implementers of the IBM compilers came to the opposite 
> conclusion.
> 
>>> I mean where do you stop?  You could in that event also you a binary 
>>> search
>>> to locate the target.
>>>
>>
>> Or a hash table ;-)
>>
> No can do. The semantics of SELECT require that the WHEN expressions be 
> evaluated in turn until one of them either compares equal to the 
> expression following SELECT or contains a 1 bit (if there is no 
> expression following SELECT).  At that point evaluation of the 
> expressions stops and the corresponding WHEN unit is executed, following 
> which control passes to the next executable statement after the SELECT 
> group, unless a goto overrides the sequence of control.  Hence SELECT is 
> essentially equivalent to the McCarthy sequential conditional.

That does not rule out the possibility of a jump table, if the WHEN 
values are constant, and I know for a fact that the old Optimizing 
Compiler would generate a jump table for a continuous or only trivially 
non-continuous case. In /theory/ a binary search or some other search 
might be used for a tremendously large list of non-trivially 
non-continuous constant WHEN values. But that is merely a question of 
compiler optimization, not semantics.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
9/11/2006 3:43:28 AM
robin wrote:
> James J. Weinkam wrote in message ...
> 
>>Peter Flass wrote:
>>
>>>Tom Linden wrote:
>>>
>>>
>>>>Sure, I just didn't find it was worth the effort to special-case.
>>
>>Obviously, the implementers of the IBM compilers came to the opposite conclusion.
>>
>>
>>>>I mean where do you stop?  You could in that event also you a binary
>>>>search
>>>>to locate the target.
>>>>
>>>
>>>Or a hash table ;-)
>>>
>>
>>No can do. The semantics of SELECT require that the WHEN expressions be
>>evaluated in turn until one of them either compares equal to the expression
>>following SELECT or contains a 1 bit (if there is no expression following
>>SELECT).
> 
> 
> When the WHEN expressions are constants, a fixed table can be used.

True.  We've been through that in the last couple of days, if you have been 
paying attention.  This is not a contradiction because if all the when values 
are constants only the first instance of any particular constant is reachable 
under the semantics so it is trivial to construct a correct jump table.
> 
> 
>> At that point evaluation of the expressions stops and the
>>corresponding WHEN unit is executed, following which control passes to the next
>>executable statement after the SELECT group, unless a goto overrides the
>>sequence of control.  Hence SELECT is essentially equivalent to the McCarthy
>>sequential conditional.
> 
> 
> 
0
jjw (608)
9/11/2006 4:47:53 AM
John W. Kennedy wrote:
> James J. Weinkam wrote:
> 
>> Peter Flass wrote:
>>
>>> Tom Linden wrote:
>>>
>>>>
>>>> Sure, I just didn't find it was worth the effort to special-case.
>>
>>
>> Obviously, the implementers of the IBM compilers came to the opposite 
>> conclusion.
>>
>>>> I mean where do you stop?  You could in that event also you a binary 
>>>> search
>>>> to locate the target.
>>>>
>>>
>>> Or a hash table ;-)
>>>
>> No can do. The semantics of SELECT require that the WHEN expressions 
>> be evaluated in turn until one of them either compares equal to the 
>> expression following SELECT or contains a 1 bit (if there is no 
>> expression following SELECT).  At that point evaluation of the 
>> expressions stops and the corresponding WHEN unit is executed, 
>> following which control passes to the next executable statement after 
>> the SELECT group, unless a goto overrides the sequence of control.  
>> Hence SELECT is essentially equivalent to the McCarthy sequential 
>> conditional.
> 
> 
> That does not rule out the possibility of a jump table, if the WHEN 
> values are constant, 

I have already pointed this out with a specific example.  That's what started 
the discussion.

and I know for a fact that the old Optimizing
> Compiler would generate a jump table for a continuous or only trivially 
> non-continuous case. In /theory/ a binary search or some other search 
> might be used for a tremendously large list of non-trivially 
> non-continuous constant WHEN values. But that is merely a question of 
> compiler optimization, not semantics.
> 
Ok, I grant the if a) the values are constants, and b) only the first instance 
of each value is included in the list, it is conceivable that a binary search 
and or hash table could be benificial, but surely this is a second order effect 
and the other posters were arguing that it isn't even worth considering a simple 
jump table.  Moreover, the suggestion I was responding to was not so qualified.
0
jjw (608)
9/11/2006 5:12:26 AM
"Tom Linden" <tom@kednos-remove.com> wrote in message 
news:op.tfosvsdbtte90l@hyrrokkin...
>
> OK, what doi you mean by OOP, and why do you think you need it?  What does  it 
> bring you that you can't otherwise express?
>
A key issue is expressiveness versus expressibility.   With a little effort, we
can express any solution in any language.  That is expressibility.   Some 
languages
make some kinds of solutions more directly expressible.  That is expressiveness.

Any attempt to do programming by extension, while abiding by the open-closed
principle, in language not explicitly designed to support that concept, is going 
to
result in a cumbersome set of code constructs.

PL/I does not seem to support OOP, at any level of expressiveness, even though
some concepts can be shoehorned in by selecting a combination of macros and
other non-OOP features.

OOP brings a capability for creating extensible (or specializable) abstractions 
to
solutions.  How does PL/I directly support inheritance?  It doesn't.   Is 
inheritance
a useful capability?   Often it is.   Can it be misused?   Often it is.

The PL/I polymorphism example, cited earlier, is pretty convoluted.   On the 
other
hand, C++ can end up with some truly obfuscated constructs too.

Choosing a programming language is like choosing any other tool.  One needs to
understand the tool and what kind of problems it will be used to solve.   OOP is
often the right method, and a language that supports it directly is usually the 
right
tool.  OOP has proven itself quite useful for large-scale programming projects,
but it has also proven itself to be a disaster when used by people who don't
understand it.

Functional languages are also tools.   Haskell is probably a much better tool 
for
many kinds of problems than Ada, PL/I, C++, or most other imperative languages.
I like to use functional languages for mathematical problems, particularly 
anything
involving calculus since it is so much easier to express solutions to those 
kinds of
problems in Lisp, Scheme, Haskell, or ML.   But, I would probably not choose
any of those languages for a data processing kind of problem.

I rather like Forth for programming microcontrollers.   I have not done that for
a good many years, but Forth is a beautiful language for getting efficiency out
of a microprocessor without having to resort to Assembler.

At present, PL/I is just another imperative language, albeit one with some very
good history and some very good features.   Most imperative language designers
have understood the importance of supporting the object-oriented paradigm. A
language that fails to evolve to support OOP is destined to see a decline in its
user base.

As I look at PL/I, I see that it could evolve to support OOP.   However,  there 
are
those who are still wondering why this is an important step in its evolution.

My original inquiry was to the effect that I could not find a deployed OOP 
version
of PL/I.   It seems to remain the case that this has not been important to those
in the PL/I community.   So be it.

I gave an example and have not yet seen anyone offer a corresponding example
in PL/I.    The questions remain.

              1) Can a PL/I abstract data type be extended with new operations
                  and data without changing the existing ADT?

              2) Can PL/I support the kind of extensibility found in C++, Java, 
Ada,
                  C#, Eiffel, or most other more contemporary languages.

              3) Can PL/I support dynamic polymorphism (not simple overloading 
as shown
                  in some posted examples)?

              4)  Is there a PL/I equivalent to an OOP class?

So far, the answer seems to be, "No."   OK.  PL/I remains a pretty good 
imperative
language.  It is not any better than most other imperative languages, when one 
does
a serious comparison.  It has some features that are better than some languages, 
but
some languages seem to be a little better in other respects.  It is a wash, at 
the imperative
programming level.

So, given that it is "a wash" (I know some of you will resent this assessment), 
what is the
incentive to use the PL/I instead of language X?   Someone might like to do a 
feature
by feature comparison, but that was not my original question.

I want to thank everyone who contributed, so far.  If anyone has knowledge of a 
good,
operational version of a PL/I compiler that expresses (expressiviity) a full 
model of
object-oriented programming -- one that is available for a real computer -- I 
would
love to hear about it.

Richard Riehle 


0
adaworks2 (748)
9/11/2006 5:57:29 AM
In <9eddc$45017cc0$5448c618$26136@news.hispeed.ch>, on 09/08/2006
   at 04:23 PM, henrik.sorensen@balcab.ch said:

>to the best of my knowledge, IF ... THEN ... ; ELSE IF ... is still
>part of PL/I, even to most recent versions :-)

Sure, but they won't know that you meant to put procedure-5 in an ELSE
clause ;-)

I meant, of course, that it's no longer the obvious way to do it, now
that SELECT is almost universally available.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
9/11/2006 5:47:41 PM
adaworks@sbcglobal.net wrote:
> So, given that it is "a wash" (I know some of you will resent this assessment), 
> what is the
> incentive to use the PL/I instead of language X?

In an IBM mainframe environment, PL/I is still the best language that 
has full support with other important subsystems such as CICS and DB2, 
the alternatives being Fortran 77, COBOL, C, and C++. Unless I 
misremember, the normal Ada compiler is GNAT, which is something of a 
square peg in the environment.

But considering language purely, although there are some aspects of PL/I 
that I wish Ada had (most importantly, zero reserved words)has many 
grave faults:
    no clear distinction between boolean and short-cut operators,
    run-time setting of exception handling,
    no OO (at least, none documented),
    stone-ax threading constructs,
    no generics (in the Ada sense), except via the macro language,
    unnecessarily clumsy overloading (called "generics" in PL/I jargon),
    no distinct integer arithmetic,
    one-size-fits-all intermediate results in fixed-point arithmetic,
    no ranging or subtyping or apples-and-oranges control,
    anonymous pointers.

In 1966, PL/I was a wonderful step forward. But it hasn't had any 
serious upgrading in decades.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
9/11/2006 8:59:00 PM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message 
news:v6kNg.243$W02.66@newsfe08.lga...
> adaworks@sbcglobal.net wrote:
>> So, given that it is "a wash" (I know some of you will resent this 
>> assessment), what is the
>> incentive to use the PL/I instead of language X?
>
> In an IBM mainframe environment, PL/I is still the best language that has full 
> support with other important subsystems such as CICS and DB2, the alternatives 
> being Fortran 77, COBOL, C, and C++. Unless I misremember, the normal Ada 
> compiler is GNAT, which is something of a square peg in the environment.
>
<snippage>

John,
  In all seriousness, can you tell me the advantages (in an IBM mainframe 
environment) for using PL/I over COBOL for "business data processing"?

Especially given the start of this thread (i.e. OO) where COBOL does have 
current support.

The (primary) things that IBM's maifnrame PL/I (over COBOL) offers that I know 
of include:
 - preprocessor
 - complex-number processing
 - bit (and boolean)
 - vector (I think) procesing)

The (primary) things that IBM's mainframe COBOL (over PL/I) offers that I know 
include:
 - OO (not very much used - but does allow full Java interoperability)
 - Report Writer (can be done in PL/I but not quite as easily)
 - Sort/Merge "verbs" (PL/I uses CALL interface and doesn't allow for 
Input/Output procedures - I think)
 - Larger "programmer" base (neither COBOL or Pl/I have lots of programmers 
getting intot the field)

***

Most of the older advantages of PL/I (that I know of) have been "met" by newer 
COBOL compilers.  I still think that PL/I (as would Fortran) would be MUCH 
better for "scientific" processing  than COBOL, but for "straight business data 
processing", I really don't see any reason - OTHER than what a shop as expertise 
in - for deciding between the two languages.

***

In general, I think that most of what one of these languages can do, the other 
can as well. Some of it "more easily" than the other, but very little can't be 
done in both.

-- 
Bill Klein
 wmklein <at> ix.netcom.com


0
wmklein (2605)
9/11/2006 9:47:56 PM
John W. Kennedy wrote:

> adaworks@sbcglobal.net wrote:
> 
>> So, given that it is "a wash" (I know some of you will resent this 
>> assessment), what is the
>> incentive to use the PL/I instead of language X?
> 
> 
> In an IBM mainframe environment, PL/I is still the best language that 
> has full support with other important subsystems such as CICS and DB2, 
> the alternatives being Fortran 77, COBOL, C, and C++. Unless I 
> misremember, the normal Ada compiler is GNAT, which is something of a 
> square peg in the environment.
> 
> But considering language purely, although there are some aspects of PL/I 
> that I wish Ada had (most importantly, zero reserved words)has many 
> grave faults:

John and I have disagreed on a lot of these points for years, mostly 
it's a matter of style.

>    no clear distinction between boolean and short-cut operators,
This has plusses and minuses, overall I'd rate it a wash,
>    run-time setting of exception handling,
This is a definite positive in my book.  With PL/I you can emulate any 
other style of exception handling you like.
>    no OO (at least, none documented),
Yup.
>    stone-ax threading constructs,
What would you want?  PL/I has both the original "TASK" procedures and 
event variables, and also supports C-style threading in newer compilers. 
  The last loses you a lot of features.  Personally, I'm planning to 
support both.
>    no generics (in the Ada sense), except via the macro language,
>    unnecessarily clumsy overloading (called "generics" in PL/I jargon),
>    no distinct integer arithmetic,
This has some merit.  Subset G has only integer arithmetic for FIXED 
BINARY data.
>    one-size-fits-all intermediate results in fixed-point arithmetic,
On the contrary, PL/I gives the programmer the maximum control over 
intermediate results, using the ADD, SUBTRACT, etc. builtins.  I know 
John is comparing PL/I to Ada, which I don't know, but compare to C you 
have near total control.  I haven't tried this, but I assume you can 
nest builtins to build an expression like [syntax from memory]:
   MULTIPLY( DIVIDE(a,5,10,0), 5, 10, 0 )
>    no ranging or subtyping or apples-and-oranges control,
This might be nice to have.
>    anonymous pointers.
Here we'll just agree to disagree.  I think typed pointers are an 
abomination, and lead to some of C's most convoluted do-nothing syntax.
I think IBM has added them in Enterprise PL/I, I assum mostly to appease 
C programmers who can't program without them.
> 
> In 1966, PL/I was a wonderful step forward. But it hasn't had any 
> serious upgrading in decades.
> 

Didn't need it.  Until recently it was the language most languages were 
trying (consciously or not) to catch up to.

0
Peter_Flass (956)
9/11/2006 10:09:45 PM
William M. Klein wrote:

>   In all seriousness, can you tell me the advantages (in an IBM mainframe 
> environment) for using PL/I over COBOL for "business data processing"?
> 
> Especially given the start of this thread (i.e. OO) where COBOL does have 
> current support.
> 
> The (primary) things that IBM's maifnrame PL/I (over COBOL) offers that I know 
> of include:
>  - preprocessor
>  - complex-number processing
>  - bit (and boolean)
>  - vector (I think) procesing)

Bit is probably the most significant, now that COBOL has better 
string-handling.  Can COBOL handle VARYING strings?  Other than that I 
think COBOL has gotten closer to PL/I over the years.  Can paragraphs 
now be called as subroutines?  How do they compare to PL/I's internal 
procedures?

> 
> The (primary) things that IBM's mainframe COBOL (over PL/I) offers that I know 
> include:
>  - OO (not very much used - but does allow full Java interoperability)
>  - Report Writer (can be done in PL/I but not quite as easily)

The SHARE library has a "report writer" for PL/I that's supposed to 
resemble the COBOL version, but I haven't looked at it, so I cant speak 
for or against it.  In the olden days, everybody always told me not to 
use Report Writer, because it was inefficient and not generally 
supported.  Do people use it more these days?

>  - Sort/Merge "verbs" (PL/I uses CALL interface and doesn't allow for 
> Input/Output procedures - I think)

Not true.  You get almost the same interface as COBOL.  It's done via 
call but you can have input and output procedures, either, both, or none 
as you want.  The only thing I don't like is you cant say "SORT ... on 
ASCENDING KEY ..." as in COBOL, but have to pass the SORT control card 
to the sort program.  I'd like to fix this sometime.

>  - Larger "programmer" base (neither COBOL or Pl/I have lots of programmers 
> getting intot the field)

True.  The thinking with PL/I was that you wouldn't have to write a 
payroll in one language, a simulation program in a second, and a 
compiler in a third.  You get one language that's at least suitable for 
all three, but COBOL has more programmers.
> 
> ***
> 
> Most of the older advantages of PL/I (that I know of) have been "met" by newer 
> COBOL compilers.  I still think that PL/I (as would Fortran) would be MUCH 
> better for "scientific" processing  than COBOL, but for "straight business data 
> processing", I really don't see any reason - OTHER than what a shop as expertise 
> in - for deciding between the two languages.
> 
> ***
> 
> In general, I think that most of what one of these languages can do, the other 
> can as well. Some of it "more easily" than the other, but very little can't be 
> done in both.
> 

0
Peter_Flass (956)
9/11/2006 10:18:33 PM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
news:ZglNg.9324$xV.8137@twister.nyroc.rr.com...
> William M. Klein wrote:
>
<snip>
> Bit is probably the most significant, now that COBOL has better 
> string-handling.  Can COBOL handle VARYING strings?  Other than that I think 
> COBOL has gotten closer to PL/I over the years.  Can paragraphs now be called 
> as subroutines?  How do they compare to PL/I's internal procedures?
>

COBOL now supports "nested programs".  These have local variables (and can 
access global ones as well).  I *think* these correspond to "internal 
procesures".

 ***

For "varing string", it says at:
  http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea4150/11.0

"The halfword prefix for PL/I varying strings is exposed, so you need to code 
the COBOL group data item with a halfword in front of the character string."

And there are "z-delimited" literals. I think you can DO what PL/I does, but it 
is not "as built-in".


FYI,
  COBOL can use the LE callabler services to handle "bits" - but I certainly 
agree that PL/I's native support is a significant advantage.  SHARE has a 
requirement for IBM to implenment BIT support - as defined in the ISO 2002 COBOL 
Standard, but I don't know how soon IBM will do it.  However, with the new 
CEE3INF callable service REQUIREING that a COBOL program be able to "read" a 
bit-map, this MIGHT be viewed as an indication that this will come sooner than 
later.

-- 
Bill Klein
 wmklein <at> ix.netcom.com 


0
wmklein (2605)
9/11/2006 11:03:35 PM
Tom Linden wrote in message ...
>On Sun, 10 Sep 2006 14:57:41 -0700, robin <robin_v@bigpond.com> wrote:
>
>> Peter Flass wrote in message ...
>>
>>> Thanks.  I think it's possinble to optimize aggressively for some
>>> special cases.  I was wondering if you had found it worthwhile to do
>>> this, and I'm glad to see I came to the same conclusion you did -- that
>>> the payoff isn't worth the effort, no matter how tempting it might seem.
>>
>> There are some cases that invite special casing, including
>> that when the cases are some letters of the alphabet, or of the digits.
>> These days, a table of 256 entries is trivial.
>>
>>> My feeling is that if the programmer really *needs* to optimize
>>> something like this they can use the 'GOTO case(i);' construct.
>>
>> The GOTO case construct is not a good one in when there is a
>> perfectly good alternative (SELECT).
>>
>I disagree, having generated code for both.

I'm not referring to code; rather to the fact that
it is unstructured, and error-prone when treated as a CASE
structure.  A non-existent jump label is not handled as well as
SELECT does.


0
robin_v (2737)
9/12/2006 3:22:20 AM
James J. Weinkam wrote in message ...
>robin wrote:
>> James J. Weinkam wrote in message ...
>>>Peter Flass wrote:
>>>>Tom Linden wrote:
>>>>>Sure, I just didn't find it was worth the effort to special-case.
>>>Obviously, the implementers of the IBM compilers came to the opposite conclusion.
>>>>>I mean where do you stop?  You could in that event also you a binary
>>>>>search to locate the target.

>>>>Or a hash table ;-)
>>>No can do. The semantics of SELECT require that the WHEN expressions be
>>>evaluated in turn until one of them either compares equal to the expression
>>>following SELECT or contains a 1 bit (if there is no expression following
>>>SELECT).
>> When the WHEN expressions are constants, a fixed table can be used.
>
>True.  We've been through that in the last couple of days, if you have been
>paying attention.

I was replying to Tom, who seems to have missed it.

>  This is not a contradiction because if all the when values
>are constants only the first instance of any particular constant is reachable
>under the semantics so it is trivial to construct a correct jump table.


0
robin_v (2737)
9/12/2006 3:22:22 AM
William M. Klein wrote:
>   In all seriousness, can you tell me the advantages (in an IBM mainframe 
> environment) for using PL/I over COBOL for "business data processing"?

I'm not familiar with the latest iteration of COBOL. As of about a 
decade ago, PL/I had, compared to IBM COBOL, based variables, functions, 
bit strings, adjustable automatic storage, VARYING character strings, 
and a good deal less useless verbiage. PL/I also had the advantage of 
/not/ having PERFORM THRU and other horrid COBOLisms, and the advantage 
of being quite stable, without having to switch dialects and apply a 
COBOL-to-COBOL translator every ten years or so.

(I mention IBM COBOL, because viewed as a portable language, it is only 
the very latest version of COBOL that has fixed -- and only optionally 
-- the original 1960 botch on intermediate-result precision. IBM COBOL, 
however, has always had almost the exact same rules as PL/I.)

>  - Sort/Merge "verbs" (PL/I uses CALL interface and doesn't allow for 
> Input/Output procedures - I think)

Not in quite the same way: it has E15 and E35 exits that are repeatedly 
called. It's roughly a wash, since any practical business programmer 
will know how to use the SORT program anyway.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
9/12/2006 3:51:33 AM
Peter Flass wrote:
> John W. Kennedy wrote:
>>    no clear distinction between boolean and short-cut operators,
> This has plusses and minuses, overall I'd rate it a wash,

Not having it defined is /not/ "a wash". The semantics of "&" and "|" 
should be defined once and for all, period.

>>    run-time setting of exception handling,
> This is a definite positive in my book.  With PL/I you can emulate any 
> other style of exception handling you like.

At the expense of readability and object-code efficiency.

>>    stone-ax threading constructs,
> What would you want?  PL/I has both the original "TASK" procedures and 
> event variables, and also supports C-style threading in newer compilers. 

Not "and also". Either/or, depending on the compiler. The original 
version corresponds to task semantics on no system I'm aware of, and 
required Herculean effort to bring off on MVT-MVS. The new version is 
primitive compared even to Java, and might as well be assembler compared 
to Ada.

>  The last loses you a lot of features.  Personally, I'm planning to 
> support both.

Then it will probably take you about a year's labor to get the RTL right.

>>    one-size-fits-all intermediate results in fixed-point arithmetic,
> On the contrary, PL/I gives the programmer the maximum control over 
> intermediate results, using the ADD, SUBTRACT, etc. builtins.

Yes, and I'm sure there are at least ten PL/I programmers who are aware 
of that, and perhaps as many as three who consistently apply it. Ada has 
a simple rule: all fixed-point multiplications and divisions /must/ 
specify a result precision.

>>    anonymous pointers.
> Here we'll just agree to disagree.  I think typed pointers are an 
> abomination, and lead to some of C's most convoluted do-nothing syntax.
> I think IBM has added them in Enterprise PL/I, I assum mostly to appease 
> C programmers who can't program without them.

I don't think you will find a single language theorist who will agree 
with you, and I don't know of any post-PL/I language (except for PL/I 
derivatives) that uses the same approach.

>> In 1966, PL/I was a wonderful step forward. But it hasn't had any 
>> serious upgrading in decades.

> Didn't need it.  Until recently it was the language most languages were 
> trying (consciously or not) to catch up to.

Ada's been around since 1983, although it took Ada '95 to completely 
catch up by adding fixed-decimal and picture features, which weren't in 
Ada's original remit.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
9/12/2006 4:15:52 AM
I don't want this to be a debate about Ada versus PL/I.

PL/I has much to recommend it.  Ada has much to recommend
it.  Niether language is perfect and anyone can find fault with either
if the look hard enough.

I agree that, for the IBM mainframe, one needs good support for
CICS and DB2 (as well as other mainframe facilities).   COBOL II
does pretty well in this respect too.  Fortran 77 has evolved to
Fortran 96 (and soon 2003), and that evolution has been quite
good.

The worst compiler I ever saw for the mainframe was an early
Ada compiler that was simply awful.   This is not a criticism of
the language, but the compiler developers had no clue what was
required of an Ada compiler at that time.  Plus, there were no
or very few, decent libraries.   Since then, Ada compilers and
available libraries have improved, but Ada still has bettter
implementations in other than the mainframe environment.

I am not saying PL/I is a bad language.  As you note, for the
mainframe it is a very good language because it is the only
viable deployed alternative to COBOL and Fortran.  However,
it is not a spectacular language and, as a procedural only
language design, it is not significantly better than some of
the competing languages.


"John W. Kennedy" <jwkenne@attglobal.net> wrote in message 
news:v6kNg.243$W02.66@newsfe08.lga...
> adaworks@sbcglobal.net wrote:
>> So, given that it is "a wash" (I know some of you will resent this 
>> assessment), what is the
>> incentive to use the PL/I instead of language X?
>
> In an IBM mainframe environment, PL/I is still the best language that has full 
> support with other important subsystems such as CICS and DB2, the alternatives 
> being Fortran 77, COBOL, C, and C++. Unless I misremember, the normal Ada 
> compiler is GNAT, which is something of a square peg in the environment.
>
GNAT could be quite effective in the mainframe environment, but no one
has requested that it be ported to that environment.  A mainframe compiler
from OC Systems does work just fine on mainframes, and it is used for
some applications I cannot discuss.

> But considering language purely, although there are some aspects of PL/I that 
> I wish Ada had (most importantly, zero reserved words)has many grave faults:
>    no clear distinction between boolean and short-cut operators,
>    run-time setting of exception handling,
>    no OO (at least, none documented),
>    stone-ax threading constructs,
>    no generics (in the Ada sense), except via the macro language,
>    unnecessarily clumsy overloading (called "generics" in PL/I jargon),
>    no distinct integer arithmetic,
>    one-size-fits-all intermediate results in fixed-point arithmetic,
>    no ranging or subtyping or apples-and-oranges control,
>    anonymous pointers.
>
> In 1966, PL/I was a wonderful step forward. But it hasn't had any serious 
> upgrading in decades.
>
The question is what we mean by "serious."  I think some important
additions have been put in place from the original design.  The SELECT
statement is one that we have discussed from time to time in this forum.

The major upgrade that PL/I needs is full support for OOP.  That current
users of the language are content with keeping it as a procedural language
is OK with me.   However, I think they are missing out on an opportunity
to get the best of what already exists in PL/I with extended capabilities.

Richard 


0
adaworks2 (748)
9/12/2006 5:25:41 AM
Again, I did not intend for this to be a debate about COBOL
versus PL/I.   Both languages have their virtues.

However, since you raise the issue of OOP, you are right that
COBOL has evolved to support the object model.

Also, COBOL, in 1985, added a number of key features that
are quite powerful.   One of the most powerful, not directly
supported by PL/I, but which can be almost-sorta kludged in
with macros, is the EVALUATE statement.   This is an extended
form of the SELECT/case/switch statement that is, as nearly as I
can tell, the most robust multi-way statement in any contemporary
programming language.

The EVALUATE statement makes conditional evaluations much
easier, more reliable, and more readable than anything anyone would
find in PL/I.   This is particularly important for business data processing
problems.

To be fair, the EVALUATE statement is more powerful than equivalent
statements, not just in PL/I, but also in Ada, C++, Java, Ruby, or any
other language you might care to name.  Well, I suppose I should have
said, "any other _imperative_  language."  Haskell and ML, both of
which are functional languages can provide good support for this kind
of construct.


"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
news:ZglNg.9324$xV.8137@twister.nyroc.rr.com...
> William M. Klein wrote:
>
>>   In all seriousness, can you tell me the advantages (in an IBM mainframe 
>> environment) for using PL/I over COBOL for "business data processing"?
>>
>> Especially given the start of this thread (i.e. OO) where COBOL does have 
>> current support.
>>
>> The (primary) things that IBM's maifnrame PL/I (over COBOL) offers that I 
>> know of include:
>>  - preprocessor
>>  - complex-number processing
>>  - bit (and boolean)
>>  - vector (I think) procesing)
>
These are not typical needs of business data processing.

> Bit is probably the most significant, now that COBOL has better 
> string-handling.  Can COBOL handle VARYING strings?  Other than that I think 
> COBOL has gotten closer to PL/I over the years.  Can paragraphs now be called 
> as subroutines?  How do they compare to PL/I's internal procedures?
>
>>
>> The (primary) things that IBM's mainframe COBOL (over PL/I) offers that I 
>> know include:
>>  - OO (not very much used - but does allow full Java interoperability)
>>  - Report Writer (can be done in PL/I but not quite as easily)
>
> The SHARE library has a "report writer" for PL/I that's supposed to resemble 
> the COBOL version, but I haven't looked at it, so I cant speak for or against 
> it.  In the olden days, everybody always told me not to use Report Writer, 
> because it was inefficient and not generally supported.  Do people use it more 
> these days?
>
>>  - Sort/Merge "verbs" (PL/I uses CALL interface and doesn't allow for 
>> Input/Output procedures - I think)
>
> Not true.  You get almost the same interface as COBOL.  It's done via call but 
> you can have input and output procedures, either, both, or none as you want. 
> The only thing I don't like is you cant say "SORT ... on ASCENDING KEY ..." as 
> in COBOL, but have to pass the SORT control card to the sort program.  I'd 
> like to fix this sometime.
>
>>  - Larger "programmer" base (neither COBOL or Pl/I have lots of programmers 
>> getting intot the field)
>
> True.  The thinking with PL/I was that you wouldn't have to write a payroll in 
> one language, a simulation program in a second, and a compiler in a third. 
> You get one language that's at least suitable for all three, but COBOL has 
> more programmers.
>>
>> ***
>>
>> Most of the older advantages of PL/I (that I know of) have been "met" by 
>> newer COBOL compilers.  I still think that PL/I (as would Fortran) would be 
>> MUCH better for "scientific" processing  than COBOL, but for "straight 
>> business data processing", I really don't see any reason - OTHER than what a 
>> shop as expertise in - for deciding between the two languages.
>>
>> ***
>>
>> In general, I think that most of what one of these languages can do, the 
>> other can as well. Some of it "more easily" than the other, but very little 
>> can't be done in both.
>>
> 


0
adaworks2 (748)
9/12/2006 5:35:45 AM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
news:J8lNg.9314$xV.8836@twister.nyroc.rr.com...
> John W. Kennedy wrote:
> This might be nice to have.
>>    anonymous pointers.
> Here we'll just agree to disagree.  I think typed pointers are an abomination, 
> and lead to some of C's most convoluted do-nothing syntax.
> I think IBM has added them in Enterprise PL/I, I assum mostly to appease C 
> programmers who can't program without them.
>>
John was originally putting this in the context of Ada.   Ada does not have
pointers in the C sense.   Yet they are type-specific. They are called "access
types" and do not have default arithmetic available as one would with
C or C++.  They are designed around a set of rules that requires them
to be safe, but default.

However, one can, using a set of library facilities, relax the type-safety if
it becomes absolutely necessary.   This includes using a special package
that supports a safe form of arithmetic.

It is important to keep in mind that Ada was designed with the goal of
detecting errors as early in the development process as possible.  This
means the compiler must detect and report errors.  Consquently, the
rules of the Ada language tend to be more strict than for other languages.
This can be annoying, but the target applications for Ada have always
been safety-critical, high-integrity software systems.

Some people feel that Ada was over-engineered.   This attitude is
especially prevalent among programmers.  Engineering is what Ada
is about.   Not programming.  Programming is something that can
be done easily in the language once the design has been well-engineered.

Richard 


0
adaworks2 (748)
9/12/2006 5:46:46 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:MJpNg.27531$rP1.11687@news-server.bigpond.net.au...
> Tom Linden wrote in message ...
>>>
>>> The GOTO case construct is not a good one in when there is a
>>> perfectly good alternative (SELECT).
>>>
>>I disagree, having generated code for both.
>
> I'm not referring to code; rather to the fact that
> it is unstructured, and error-prone when treated as a CASE
> structure.  A non-existent jump label is not handled as well as
> SELECT does.
>
This is a situation where I agree with Robin.   Computed
go to statements are more error-prone than an authentic
case statement.  They are also more difficult to update with
later requirements.
>
Richard 


0
adaworks2 (748)
9/12/2006 5:50:37 AM
John W. Kennedy wrote:

(someone wrote)

>> Here we'll just agree to disagree.  I think typed pointers are an 
>> abomination, and lead to some of C's most convoluted do-nothing syntax.
>> I think IBM has added them in Enterprise PL/I, I assum mostly to 
>> appease C programmers who can't program without them.

> I don't think you will find a single language theorist who will agree 
> with you, and I don't know of any post-PL/I language (except for PL/I 
> derivatives) that uses the same approach.

If you want to do the things people do in C, I suppose I agree.

One thing it does fairly well, though, is locate mode I/O.
Instead of copying data to/from an I/O buffer it can read/write
directly from a structure in memory.  Well, BSAM and BDAM would do that,
for QSAM it would mean one fewer buffer copy than would otherwise be
needed.

For list processing, where all pointers point to the same kind of 
structure, it also doesn't matter so much.

-- glen


0
gah (12851)
9/12/2006 6:59:40 AM
glen herrmannsfeldt wrote:
> One thing it does fairly well, though, is locate mode I/O.
> Instead of copying data to/from an I/O buffer it can read/write
> directly from a structure in memory.  Well, BSAM and BDAM would do that,
> for QSAM it would mean one fewer buffer copy than would otherwise be
> needed.
> 

I agree, but "most" systems no longer support this, so it's of no 
benefit.  Copying (and re-copying) is the rule these days.

0
Peter_Flass (956)
9/12/2006 10:58:00 AM
On Mon, 11 Sep 2006 22:50:37 -0700, <adaworks@sbcglobal.net> wrote:

>
> "robin" <robin_v@bigpond.com> wrote in message
> news:MJpNg.27531$rP1.11687@news-server.bigpond.net.au...
>> Tom Linden wrote in message ...
>>>>
>>>> The GOTO case construct is not a good one in when there is a
>>>> perfectly good alternative (SELECT).
>>>>
>>> I disagree, having generated code for both.
>>
>> I'm not referring to code; rather to the fact that
>> it is unstructured, and error-prone when treated as a CASE
>> structure.  A non-existent jump label is not handled as well as
>> SELECT does.
>>
> This is a situation where I agree with Robin.   Computed
> go to statements are more error-prone than an authentic
> case statement.  They are also more difficult to update with
> later requirements.
>>
> Richard
>
>
As I mentioned previously we define a label(*) which is the equivalent
of otherwise.  With this constuct the two locutions are isomorphic.


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/12/2006 12:42:48 PM
On Mon, 11 Sep 2006 20:22:22 -0700, robin <robin_v@bigpond.com> wrote:

> James J. Weinkam wrote in message ...
>> robin wrote:
>>> James J. Weinkam wrote in message ...
>>>> Peter Flass wrote:
>>>>> Tom Linden wrote:
>>>>>> Sure, I just didn't find it was worth the effort to special-case.
>>>> Obviously, the implementers of the IBM compilers came to the opposite  
>>>> conclusion.
>>>>>> I mean where do you stop?  You could in that event also you a binary
>>>>>> search to locate the target.
>
>>>>> Or a hash table ;-)
>>>> No can do. The semantics of SELECT require that the WHEN expressions  
>>>> be
>>>> evaluated in turn until one of them either compares equal to the  
>>>> expression
>>>> following SELECT or contains a 1 bit (if there is no expression  
>>>> following
>>>> SELECT).
>>> When the WHEN expressions are constants, a fixed table can be used.
>>
>> True.  We've been through that in the last couple of days, if you have  
>> been
>> paying attention.
>
> I was replying to Tom, who seems to have missed it.

No I saw it, I had nothing to add to mu previous point that special casing
didn't seem worth it.
>
>>  This is not a contradiction because if all the when values
>> are constants only the first instance of any particular constant is  
>> reachable
>> under the semantics so it is trivial to construct a correct jump table.
>
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/12/2006 12:45:48 PM
Peter Flass <Peter_Flass@yahoo.com> wrote:

(snip on locate mode I/O)
> I agree, but "most" systems no longer support this, so it's of no 
> benefit.  Copying (and re-copying) is the rule these days.

Just like trailer encapsulation for TCP/IP never caught on.

A traditional TCP/IP stack requires copying the data to put the
TCP header on, and then the IP header.  At some point, the idea of
putting the header information at the end, to avoid excessive
copying came along, but it never caught on.

-- glen
0
gah1 (524)
9/12/2006 5:33:23 PM
Shmuel (Seymour J.) Metz wrote:

>>to the best of my knowledge, IF ... THEN ... ; ELSE IF ... is still
>>part of PL/I, even to most recent versions :-)
> 
> Sure, but they won't know that you meant to put procedure-5 in an ELSE
> clause ;-)
> 
touche! 
LOL
0
9/12/2006 9:36:46 PM
Peter Flass wrote:
> glen herrmannsfeldt wrote:
>> One thing it does fairly well, though, is locate mode I/O.
>> Instead of copying data to/from an I/O buffer it can read/write
>> directly from a structure in memory.  Well, BSAM and BDAM would do that,
>> for QSAM it would mean one fewer buffer copy than would otherwise be
>> needed.
>>
> 
> I agree, but "most" systems no longer support this, so it's of no 
> benefit.  Copying (and re-copying) is the rule these days.

It isn't even supported in VSAM under MVS.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
9/13/2006 4:05:09 AM
adaworks@sbcglobal.net wrote:
> The question is what we mean by "serious."  I think some important
> additions have been put in place from the original design.  The SELECT
> statement is one that we have discussed from time to time in this forum.

That's from the 70's.

The 90's saw typed pointers as an alternative to the original anonymous 
pointers, but with many restrictions to 'em that were more suggestive of 
compiler limitations than design -- though I think they've been relaxed 
more recently. The 90's also saw the third major redesign of the macro 
language, and the abandonment of the original tasking model (which was 
hellish to implement on any existing operating system).

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
9/13/2006 4:13:57 AM
John W. Kennedy wrote in message ...
>William M. Klein wrote:
>>   In all seriousness, can you tell me the advantages (in an IBM mainframe
>> environment) for using PL/I over COBOL for "business data processing"?
>
>I'm not familiar with the latest iteration of COBOL. As of about a
>decade ago, PL/I had, compared to IBM COBOL, based variables, functions,
>bit strings, adjustable automatic storage, VARYING character strings,

and VARYING bit strings.

Arrays were never "adjustable automatic".
They have always been fully automatic, that is, dynamically changeable.

>and a good deal less useless verbiage.


0
robin_v (2737)
9/15/2006 1:20:02 AM
John W. Kennedy wrote in message <5wqNg.116$_K1.12@newsfe11.lga>...
>Peter Flass wrote:
>> John W. Kennedy wrote:
>>>    no clear distinction between boolean and short-cut operators,
>> This has plusses and minuses, overall I'd rate it a wash,
>
>Not having it defined is /not/ "a wash". The semantics of "&" and "|"
>should be defined once and for all, period.
>
>>>    run-time setting of exception handling,
>> This is a definite positive in my book.  With PL/I you can emulate any
>> other style of exception handling you like.
>
>At the expense of readability and object-code efficiency.

That's false.
And anyway, the important thing is that it's
great for catching errors.


    PL/I exception handling readily lends itself to
extended range floating-point.

>>>    stone-ax threading constructs,
>> What would you want?  PL/I has both the original "TASK" procedures and
>> event variables, and also supports C-style threading in newer compilers.
>
>Not "and also". Either/or, depending on the compiler. The original
>version corresponds to task semantics on no system I'm aware of, and
>required Herculean effort to bring off on MVT-MVS. The new version is
>primitive compared even to Java, and might as well be assembler compared
>to Ada.
>
>>  The last loses you a lot of features.  Personally, I'm planning to
>> support both.
>
>Then it will probably take you about a year's labor to get the RTL right.

Why don't you have a good day!

>>>    one-size-fits-all intermediate results in fixed-point arithmetic,
>> On the contrary, PL/I gives the programmer the maximum control over
>> intermediate results, using the ADD, SUBTRACT, etc. builtins.
>
>Yes, and I'm sure there are at least ten PL/I programmers who are aware
>of that,

Good days must be hard to come by!

> and perhaps as many as three who consistently apply it. Ada has
>a simple rule: all fixed-point multiplications and divisions /must/
>specify a result precision.

Then use Ada.
    The point is that in PL/I you have a choice.
Most operations do not need an explicit specification of the precision
of the result.  And the computation (i.e., expression) is much clearer as
a consequence.

>>>    anonymous pointers.
>> Here we'll just agree to disagree.  I think typed pointers are an
>> abomination, and lead to some of C's most convoluted do-nothing syntax.
>> I think IBM has added them in Enterprise PL/I, I assum mostly to appease
>> C programmers who can't program without them.
>
>I don't think you will find a single language theorist who will agree
>with you,

Nonsense.

> and I don't know of any post-PL/I language (except for PL/I
>derivatives) that uses the same approach.
>
>>> In 1966, PL/I was a wonderful step forward. But it hasn't had any
>>> serious upgrading in decades.

In 1994, IBM PL/I for the PC had significant additions.

>> Didn't need it.  Until recently it was the language most languages were
>> trying (consciously or not) to catch up to.

That's right.

>Ada's been around since 1983, although it took Ada '95 to completely
>catch up by adding fixed-decimal and picture features, which weren't in
>Ada's original remit.

PL/I didn't need an "upgrade" for those, because it's had them
since 1966.

    And that's the whole story.  PL/I didn't undergo "serious upgrading" because
it didn't need them.  The stuff was already in it.


0
robin_v (2737)
9/15/2006 1:20:03 AM
William M. Klein wrote in message ...
>"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
>news:v6kNg.243$W02.66@newsfe08.lga...
>> adaworks@sbcglobal.net wrote:
>>> So, given that it is "a wash" (I know some of you will resent this
>>> assessment), what is the
>>> incentive to use the PL/I instead of language X?
>>
>> In an IBM mainframe environment, PL/I is still the best language that has full
>> support with other important subsystems such as CICS and DB2, the alternatives
>> being Fortran 77, COBOL, C, and C++. Unless I misremember, the normal Ada
>> compiler is GNAT, which is something of a square peg in the environment.
>>
><snippage>
>
>John,
>  In all seriousness, can you tell me the advantages (in an IBM mainframe
>environment) for using PL/I over COBOL for "business data processing"?

The primary advantages of PL/I for commercial work
include:
1.    Clear and concise code, without being terse;
2.    Error control, and consequent ease of recovery;
3.    Inbuilt diagnostic aids;
4.    Suitability for large projects (an outcome of (2) and (3) above);
5.    Comprehensive functions for decimal arithmetic;
6.    A DATE data type, and automatic handling of 2 and 4-digit years
        with century windowing; [COBOL too]
7.    Bit strings;
8.    VARYING character strings (two kinds: length determined, and
       zero-terminated for compatibility with C);
9.    Extensive string-handling fuinctions;
10.    Data structures for commercial work; including BY NAME option;
11.  Array handling;
12.   Preprocessor;
13.    Productivity.

As well as these, not for commercial work, are:

14.    complex arithmetic;
15.    Improved list-processing facilities (I guess these could be used
         for commercial work too);

>The (primary) things that IBM's maifnrame PL/I (over COBOL) offers that I know
>of include:
> - preprocessor
> - complex-number processing
> - bit (and boolean)
> - vector (I think) procesing)
>
>The (primary) things that IBM's mainframe COBOL (over PL/I) offers that I know
>include:
> - OO (not very much used - but does allow full Java interoperability)
> - Report Writer (can be done in PL/I but not quite as easily)
> - Sort/Merge "verbs" (PL/I uses CALL interface and doesn't allow for
>Input/Output procedures - I think)
> - Larger "programmer" base (neither COBOL or Pl/I have lots of programmers
>getting intot the field)
>
>***
>
>Most of the older advantages of PL/I (that I know of) have been "met" by newer
>COBOL compilers.  I still think that PL/I (as would Fortran) would be MUCH
>better for "scientific" processing  than COBOL, but for "straight business data
>processing", I really don't see any reason - OTHER than what a shop as expertise
>in - for deciding between the two languages.

Other than the above 1-13.


0
robin_v (2737)
9/15/2006 1:20:04 AM
Tom Linden wrote in message ...
>On Mon, 11 Sep 2006 22:50:37 -0700, <adaworks@sbcglobal.net> wrote:
>>
>> "robin" <robin_v@bigpond.com> wrote in message
>> news:MJpNg.27531$rP1.11687@news-server.bigpond.net.au...
>>> Tom Linden wrote in message ...
>>>>>
>>>>> The GOTO case construct is not a good one in when there is a
>>>>> perfectly good alternative (SELECT).
>>>>>
>>>> I disagree, having generated code for both.
>>>
>>> I'm not referring to code; rather to the fact that
>>> it is unstructured, and error-prone when treated as a CASE
>>> structure.  A non-existent jump label is not handled as well as
>>> SELECT does.
>>>
>> This is a situation where I agree with Robin.   Computed
>> go to statements are more error-prone than an authentic
>> case statement.  They are also more difficult to update with
>> later requirements.
>>>
>> Richard

>As I mentioned previously we define a label(*) which is the equivalent
>of otherwise.  With this constuct the two locutions are isomorphic.

Then there's the need to have GO TOs at the end of each segment.


0
robin_v (2737)
9/15/2006 1:20:05 AM
robin wrote:
> 
> Arrays were never "adjustable automatic".
> They have always been fully automatic, that is, dynamically changeable.
> 
Please give rigorous definitions of "adjustable automatic" and "fully automatic" 
and/or "dynamically changeable".
0
jjw (608)
9/15/2006 7:16:02 AM
I was (sort-of with you until your last statement, but let's look at 1-13 for 
today's IBM mainframe COBOL environment (which is all I was asking about)

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"robin" <robin_v@bigpond.com> wrote in message 
news:8dnOg.29059$rP1.14238@news-server.bigpond.net.au...
> William M. Klein wrote in message ...
>>"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
>>news:v6kNg.243$W02.66@newsfe08.lga...
>>> adaworks@sbcglobal.net wrote:
>>>> So, given that it is "a wash" (I know some of you will resent this
>>>> assessment), what is the
>>>> incentive to use the PL/I instead of language X?
>>>
>>> In an IBM mainframe environment, PL/I is still the best language that has 
>>> full
>>> support with other important subsystems such as CICS and DB2, the 
>>> alternatives
>>> being Fortran 77, COBOL, C, and C++. Unless I misremember, the normal Ada
>>> compiler is GNAT, which is something of a square peg in the environment.
>>>
>><snippage>
>>
>>John,
>>  In all seriousness, can you tell me the advantages (in an IBM mainframe
>>environment) for using PL/I over COBOL for "business data processing"?
>
> The primary advantages of PL/I for commercial work
> include:
> 1.    Clear and concise code, without being terse;
  Non-COBOL programmers consider COBOL "verbose" - but I have never heard an 
experienced COBOL programmer think this

> 2.    Error control, and consequent ease of recovery;
 On an IBM mainframe, full LE condition handling is available (along with 
traditional COBOL declaratives)

> 3.    Inbuilt diagnostic aids;
 Besides the fact that there have always been 3rd party debugging tools (more 
for COBOL than PL/I), I don't know what "built in" tools you think are better in 
PL/I than COBOL.

> 4.    Suitability for large projects (an outcome of (2) and (3) above);
 If more "larger projects" are (and have been) done in COBOL than in PL/I, why 
do you think this is? I think this statement is simply a "what you are used to - 
is what is best for you" situation.

> 5.    Comprehensive functions for decimal arithmetic;
Ain't nothing in PL/I that hasn't been in COBOL since day 1 (before the 
beginning of PL/I)

> 6.    A DATE data type, and automatic handling of 2 and 4-digit years
>        with century windowing; [COBOL too]
 For IBM mainframes, this has been available since within 12 months of when PL/I 
got it. (4/2 year date handling is also portable now that it is included in the 
ANSI/ISO Standard - but admittedly DATE data-types are not.)

> 7.    Bit strings;
 Absoltuely better in PL/I than COBOL (as I originally stated.  However, LE 
callable services can handle most of what any COBOL application might ever WANT 
to do.

> 8.    VARYING character strings (two kinds: length determined, and
>       zero-terminated for compatibility with C);
"z-terminated" literals have been available in IBM COBOL for years.  "VARYING" 
with prefixed length is also available - but the length is visible.  Most COBOL 
(and possibly some other application) programmers would consider this an 
advantage - but I am certainly willing to say it is a "design" decision. 
Interestingly enough the currently under-development COBOL Standard is including 
both of these types of "native" data-types.

> 9.    Extensive string-handling fuinctions;
 Some, but certainly not much available in PL/I that isn't already available in 
COBOL.  Only "TRIM" has been misign and ANSI/ISO is adding that.  (STRING andf 
UNSTRING statements in COBOL are as powerful as anything that I know of in 
PL/I - but this may be my ignorance)

> 10.    Data structures for commercial work; including BY NAME option;
I don't think that you could convince any COBOL site that there ALL the 
"data-types" that they need for commercial processing.

> 11.  Array handling;
Again, been in COBOL since the "beginnning" (unless you are talking about VECTOR 
processing, which I admit isn't in COBOL - but rarely needed for "business data 
processing"

> 12.   Preprocessor;
 Absolutely better in PL/I (and I included it in my original list)

> 13.    Productivity.
Not only is this totally a matter of "what you are used to" - there are 
significantly MORE 3rd party COBOL "productivity" tools than there are for PL/I 
and this is NOT because you can't be productive in COBOL, but simply because of 
its long standing popularity among IBM commercial data processing sites.
>
> As well as these, not for commercial work, are:
>
> 14.    complex arithmetic;
> 15.    Improved list-processing facilities (I guess these could be used
>         for commercial work too);
>
>>The (primary) things that IBM's maifnrame PL/I (over COBOL) offers that I know
>>of include:
>> - preprocessor
>> - complex-number processing
>> - bit (and boolean)
>> - vector (I think) procesing)
>>
>>The (primary) things that IBM's mainframe COBOL (over PL/I) offers that I know
>>include:
>> - OO (not very much used - but does allow full Java interoperability)
>> - Report Writer (can be done in PL/I but not quite as easily)
>> - Sort/Merge "verbs" (PL/I uses CALL interface and doesn't allow for
>>Input/Output procedures - I think)
>> - Larger "programmer" base (neither COBOL or Pl/I have lots of programmers
>>getting intot the field)
>>
>>***
>>
>>Most of the older advantages of PL/I (that I know of) have been "met" by newer
>>COBOL compilers.  I still think that PL/I (as would Fortran) would be MUCH
>>better for "scientific" processing  than COBOL, but for "straight business 
>>data
>>processing", I really don't see any reason - OTHER than what a shop as 
>>expertise
>>in - for deciding between the two languages.
>
> Other than the above 1-13.
>
> 


0
wmklein (2605)
9/15/2006 9:12:38 AM
John W. Kennedy wrote in message ...
>In an IBM mainframe environment, PL/I is still the best language that
>has full support with other important subsystems such as CICS and DB2,
>the alternatives being Fortran 77, COBOL, C, and C++. Unless I
>misremember, the normal Ada compiler is GNAT, which is something of a
>square peg in the environment.
>
>But considering language purely, although there are some aspects of PL/I
>that I wish Ada had (most importantly, zero reserved words)has many
>grave faults:
>    no clear distinction between boolean and short-cut operators,

If you use the language as intended, Boolean works fine.

>    run-time setting of exception handling,

Error handling is the best part of PL/I.
As well as being flexible, it enables things like extended range floating-point.

>    no OO (at least, none documented),

Have you considered using the preprocessor?

>    stone-ax threading constructs,
>    no generics (in the Ada sense), except via the macro language,
>    unnecessarily clumsy overloading (called "generics" in PL/I jargon),

user generic procedures are fine in PL/I.
(they are called "generics" in other languages too)
PL/I had then in 1966; other languages didn't get them until much later --
Fortran not until 1991.

>    no distinct integer arithmetic,

Non needed; integer arithmetic is obtained by using
approprite declarations.

>    one-size-fits-all intermediate results in fixed-point arithmetic,

You can use the built-in functions whenever you wish
a precision that's different from the default.

There is no "one-size-fits-all".

>    no ranging or subtyping or apples-and-oranges control,

typed definitions are available.

>    anonymous pointers.

You can use the typed pointers whenever you want.


0
robin_v (2737)
9/17/2006 4:21:35 PM
On Sun, 17 Sep 2006 09:21:35 -0700, robin <robin_v@bigpond.com> wrote:

> You can use the typed pointers whenever you want.

Typed pointers is an oxymoron, it is attributed pointers.

Pointers are a bona fide data type in PL/I unlike other languages,
but you knew that.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/17/2006 11:50:35 PM
William M. Klein wrote in message ...
>I was (sort-of with you until your last statement, but let's look at 1-13 for
>today's IBM mainframe COBOL environment (which is all I was asking about)
>
>--
>Bill Klein
> wmklein <at> ix.netcom.com
>"robin" <robin_v@bigpond.com> wrote in message
>news:8dnOg.29059$rP1.14238@news-server.bigpond.net.au...
>> William M. Klein wrote in message ...
>>>"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
>>>news:v6kNg.243$W02.66@newsfe08.lga...
>>>> adaworks@sbcglobal.net wrote:
>>>>> So, given that it is "a wash" (I know some of you will resent this
>>>>> assessment), what is the
>>>>> incentive to use the PL/I instead of language X?
>>>>
>>>> In an IBM mainframe environment, PL/I is still the best language that has
>>>> full
>>>> support with other important subsystems such as CICS and DB2, the
>>>> alternatives
>>>> being Fortran 77, COBOL, C, and C++. Unless I misremember, the normal Ada
>>>> compiler is GNAT, which is something of a square peg in the environment.
>>>>
>>><snippage>
>>>
>>>John,
>>>  In all seriousness, can you tell me the advantages (in an IBM mainframe
>>>environment) for using PL/I over COBOL for "business data processing"?
>>
>> The primary advantages of PL/I for commercial work
>> include:
>> 1.    Clear and concise code, without being terse;
>  Non-COBOL programmers consider COBOL "verbose" - but I have never heard an
>experienced COBOL programmer think this

That's probably because he was thnking. ;^)

>> 2.    Error control, and consequent ease of recovery;
> On an IBM mainframe, full LE condition handling is available (along with
>traditional COBOL declaratives)

I'm not referring to LE handling.
I'm referring to what's available in PL/I.

>> 3.    Inbuilt diagnostic aids;
> Besides the fact that there have always been 3rd party debugging tools (more
>for COBOL than PL/I)

None needed for PL/I.  They are part of the language.

>, I don't know what "built in" tools you think are better in
>PL/I than COBOL.

The ability to turn on and to turn off any off at any statement :-
* subscript checking and string bounds checking
* overflow,
* underflow,
* fixed-point overflow,
As well, these can be turned on and off for an entire procedure.
Sundry other PL/I conditions can be raised, such as the ATTENTION
condition to interrupt a program, and to resume it at precisely
the point of interruption, after having done any or all of :-
* nothing,
* printed values of variables;
* changed the values of any variables.
And so on, all under language-defined facilities.

>> 4.    Suitability for large projects (an outcome of (2) and (3) above);
> If more "larger projects" are (and have been) done in COBOL than in PL/I, why
>do you think this is? I think this statement is simply a "what you are used to -
>is what is best for you" situation.

Your response doesn't change the fact that PL/I is more suitable.

>> 5.    Comprehensive functions for decimal arithmetic;
>Ain't nothing in PL/I that hasn't been in COBOL since day 1 (before the
>beginning of PL/I)

Except COMPLEX, conversions between BIT and DECIMAL,
and probably more.

>> 6.    A DATE data type, and automatic handling of 2 and 4-digit years
>>        with century windowing; [COBOL too]
> For IBM mainframes, this has been available since within 12 months of when PL/I
>got it.

I did mention that COBOL had it too.

> (4/2 year date handling is also portable now that it is included in the
>ANSI/ISO Standard - but admittedly DATE data-types are not.)

Then how are mixed 2-digit years and 4-digit years handled automatically?

>> 7.    Bit strings;
> Absoltuely better in PL/I than COBOL (as I originally stated.  However, LE
>callable services can handle most of what any COBOL application might ever WANT
>to do.

BIT strings and bit arrays are used in surveys where the answers are
of the yes/no kind.  I was reminded of this by a recent event.

Just a few weeks ago, while researching a first generation computer,
I found that the input data was punched on cards, 12 answers per column,
in 32 columns (giving 384 values per 80-column card).
The data was held in storage as bit strings.
LE callable services are not available to non-IBM platforms.

>> 8.    VARYING character strings (two kinds: length determined, and
>>       zero-terminated for compatibility with C);
>"z-terminated" literals have been available in IBM COBOL for years.  "VARYING"
>with prefixed length is also available - but the length is visible.

You said that before.

>  Most COBOL
>(and possibly some other application) programmers would consider this an
>advantage - but I am certainly willing to say it is a "design" decision.
>Interestingly enough the currently under-development COBOL Standard is including
>both of these types of "native" data-types.
>
>> 9.    Extensive string-handling fuinctions;
> Some, but certainly not much available in PL/I that isn't already available in
>COBOL.  Only "TRIM" has been misign and ANSI/ISO is adding that.  (STRING andf
>UNSTRING statements in COBOL are as powerful as anything that I know of in
>PL/I - but this may be my ignorance)
>
>> 10.    Data structures for commercial work; including BY NAME option;
>I don't think that you could convince any COBOL site that there ALL the
>"data-types" that they need for commercial processing.
>
>> 11.  Array handling;
>Again, been in COBOL since the "beginnning" (unless you are talking about VECTOR
>processing, which I admit isn't in COBOL -

I'm referring to vector/matrix/multi-dimensional array handling,
not table handling.

> but rarely needed for "business data processing"

Naturally, as it's not in COBOL, but nevertheless, it's still needed.

>> 12.   Preprocessor;
> Absolutely better in PL/I (and I included it in my original list)
>
>> 13.    Productivity.
>Not only is this totally a matter of "what you are used to" - there are
>significantly MORE 3rd party COBOL "productivity" tools than there are for PL/I
>and this is NOT because you can't be productive in COBOL, but simply because of
>its long standing popularity among IBM commercial data processing sites.

I'm not referring to productivity tools.
I'm referring PL/I as a language.
The verbosity of COBOL works against it.

>> As well as these, not for commercial work, are:
>>
>> 14.    complex arithmetic;
>> 15.    Improved list-processing facilities (I guess these could be used
>>         for commercial work too);


0
robin_v (2737)
9/18/2006 6:04:52 AM
William M. Klein (wmklein <at> ix.netcom.com) wrote in message ...

>"robin" <robin_v@bigpond.com> wrote in message
>news:8dnOg.29059$rP1.14238@news-server.bigpond.net.au...

>> 9.    Extensive string-handling functions;
> Some, but certainly not much available in PL/I that isn't already available in
>COBOL.  Only "TRIM" has been misign and ANSI/ISO is adding that.  (STRING andf
>UNSTRING statements in COBOL are as powerful as anything that I know of in
>PL/I - but this may be my ignorance)

Just for the record, these and more are available in PL/I:-

(BTW, strings available include CHARACTER, MIXED, GRAPHIC,
WIDECHAR, and BIT)

*    CHAR
*    STRING
*    UNSPEC
*    SEARCH
*    SEARCHR (search in reverse)
*    VERIFY
*    VERIFYR (verify in reverse)
*    INDEX
*    TRANSLATE
*    LEFT
*    RIGHT
*    CENTER
*    CENTERRIGHT, CENTERLEFT
*    TRIM (mainly used for removing blanks from the beginning and/or end
      of a string, but is also used for removing any combination of characters
      from either or both ends of a string.  It's like a combinarion of VERIFY,
      VERIFYR, and SUBSTR).
*    LENGTH
*    MAXLENGTH
*    LOWERCASE returns the lower-case version of the string argument.
*    UPPERCASE returns the upper-case version of the string argument.
*    PLIDUMP produces a formatted dump of storage used by the program.
*    PLISAXA and PLISAXB invoke the high-speed XML parser.
    PLISAXA process an XML document held in memory,
    while PLISAXB processes a file of XML data.
    Supports 21 EBCDIC code pages and 3 ASCII code pages.
*    BITLOCATION(x) returns the location (in the range 0 to 7) of x
     within the byte where x is stored. (x is UNALIGNED BIT.)
*    CURRENTSIZE returns the number of bytes
     in a variable or structure.
*    EDIT(Value, picture_pattern) returns Value in the form
     specified by the picture pattern.
     e.g., EDIT (12.345, '9999.999') returns '0012.345'
*    HEX returns the hexadecimal form of the character string
     argument. HEX('abc') returns '616263' on an ASCII machine,
     and '818283' on an EBCDIC machine. HEX(S, ' ') is the same
     as HEX(S), except that blanks are inserted in the returned
     hexadecimal string - after every eighth character.
*    HEXIMAGE is like HEX. HEXIMAGE(S, n) returns n characters
     at the address S (as a hexadecial string).
*    HEXIMAGE(S, n, c) is the same as HEXIMAGE(S, n)
     except that the character c is inserted after every eighth character
     of the hexadecimal string.
*    TALLY(S, T) counts the number of times that string T appears
     in string S.
*    MEMINDEX is like INDEX.
*    MEMSEARCH is like SEARCH.
*    MEMSEARCH (b, k, key)
*    MEMSEARCH
*    MEMSEARCHR is the same as MEMSEARCH, except that
     the search is backwards
*    MEMVERIFY is like VERIFY
*    MEMVERIFY
*    MEMSEARCH
*    MEMVERIFYR is the same as MEMVERIFY except that the
     search is backwards
*    REPLACEBY2 is like TRANSLATE. Usage:
     REPLACEBY2 (string, rep, original) searches a copy of string.
     If a character in <original> exists in <string>, the corresponding
     pair of characters in <rep> are substituted.
*    XMLCHAR for handling XML strings.
*    BIT
*    COLLATE
*    REPATTERN (for transforming a date into a convenient
      printable form).
*    RANK
*    SUBSTR
*    ONCHAR
*    ONSOURCE
Plus similar ON- functions for GRAPHIC and WIDECHAR.


0
robin_v (2737)
9/18/2006 6:04:53 AM
see below

I really "hate" language "wars" - but your (Robin's) inability to distinguish 
between "opinion" and "fact" really is why D.F. hates the "FAQ" and one place 
where YOUR "creditability" suffers - not just among those who prefer another 
language but also among some I have read who support PL/I.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"robin" <robin_v@bigpond.com> wrote in message 
news:8GqPg.30657$rP1.17975@news-server.bigpond.net.au...
> William M. Klein wrote in message ...
>>I was (sort-of with you until your last statement, but let's look at 1-13 for
>>today's IBM mainframe COBOL environment (which is all I was asking about)
>>
>>--
>>Bill Klein
>> wmklein <at> ix.netcom.com
>>"robin" <robin_v@bigpond.com> wrote in message
>>news:8dnOg.29059$rP1.14238@news-server.bigpond.net.au...
>>> William M. Klein wrote in message ...
>>>>"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
>>>>news:v6kNg.243$W02.66@newsfe08.lga...
>>>>> adaworks@sbcglobal.net wrote:
>>>>>> So, given that it is "a wash" (I know some of you will resent this
>>>>>> assessment), what is the
>>>>>> incentive to use the PL/I instead of language X?
>>>>>
>>>>> In an IBM mainframe environment, PL/I is still the best language that has
>>>>> full
>>>>> support with other important subsystems such as CICS and DB2, the
>>>>> alternatives
>>>>> being Fortran 77, COBOL, C, and C++. Unless I misremember, the normal Ada
>>>>> compiler is GNAT, which is something of a square peg in the environment.
>>>>>
>>>><snippage>
>>>>
>>>>John,
>>>>  In all seriousness, can you tell me the advantages (in an IBM mainframe
>>>>environment) for using PL/I over COBOL for "business data processing"?
>>>
>>> The primary advantages of PL/I for commercial work
>>> include:
>>> 1.    Clear and concise code, without being terse;
>>  Non-COBOL programmers consider COBOL "verbose" - but I have never heard an
>>experienced COBOL programmer think this
>
> That's probably because he was thnking. ;^)
>
>>> 2.    Error control, and consequent ease of recovery;
>> On an IBM mainframe, full LE condition handling is available (along with
>>traditional COBOL declaratives)
>
> I'm not referring to LE handling.
> I'm referring to what's available in PL/I.

How do you run PL/I "error handling" without USING LE for the run-time?
 CALL is part of COBOL so it LE condition handling is part of IBM mainframe 
COBOL.

>
>>> 3.    Inbuilt diagnostic aids;
>> Besides the fact that there have always been 3rd party debugging tools (more
>>for COBOL than PL/I)
>
> None needed for PL/I.  They are part of the language.
None NEEDED for COBOL, but there are additional tools available. What do you 
think PL/I offers that COBOL doesn't?
>
>>, I don't know what "built in" tools you think are better in
>>PL/I than COBOL.
>
> The ability to turn on and to turn off any off at any statement :-
> * subscript checking and string bounds checking
     - See COBOL SSRANGE
> * overflow,
  - Like the ON VERFLOW (or ON SIZE) phrase.
> * underflow,
 - Can't happen in COBOL, so no need

> * fixed-point overflow,
  ON SIZE ERROR phrase
> As well, these can be turned on and off for an entire procedure.
 - Also available via LE

> Sundry other PL/I conditions can be raised, such as the ATTENTION
> condition to interrupt a program, and to resume it at precisely
> the point of interruption, after having done any or all of :-
> * nothing,
 - Again fully supporte dy LE (again, you can't run IBM mainframe without it 
either)

> * printed values of variables;
 - DISPLAY statement

> * changed the values of any variables.
> And so on, all under language-defined facilities.
 - Anyone who doesn't consider LE part of the COBOL language should show a run 
of currently supported PL/I *without* LE.  It *is* part of the IBM mainframe 
language.
>
>>> 4.    Suitability for large projects (an outcome of (2) and (3) above);
>> If more "larger projects" are (and have been) done in COBOL than in PL/I, why
>>do you think this is? I think this statement is simply a "what you are used 
>>to -
>>is what is best for you" situation.
>
> Your response doesn't change the fact that PL/I is more suitable.
  Based on what FACT?  (otrher than your opinion)  Certainly NOT based on 
"independent" mangagement decisions at the MAJORITY of IBM mainframe shops.

>
>>> 5.    Comprehensive functions for decimal arithmetic;
>>Ain't nothing in PL/I that hasn't been in COBOL since day 1 (before the
>>beginning of PL/I)
>
> Except COMPLEX, conversions between BIT and DECIMAL,
> and probably more.
  What does "COMPLEX" and "BIT" have to with DECIMAL?  (I agree that PL/I has 
support for BIT and COMPLEX not available in COBOL.  See my original note.  - 
Just like PL/I doesn't support OO or Report Writer.)

>
>>> 6.    A DATE data type, and automatic handling of 2 and 4-digit years
>>>        with century windowing; [COBOL too]
>> For IBM mainframes, this has been available since within 12 months of when 
>> PL/I
>>got it.
>
> I did mention that COBOL had it too.
 So why is it listed in "1-13"
>
>> (4/2 year date handling is also portable now that it is included in the
>>ANSI/ISO Standard - but admittedly DATE data-types are not.)
>
> Then how are mixed 2-digit years and 4-digit years handled automatically?
 Thru "Millentium Language Extensions"
>
>>> 7.    Bit strings;
>> Absoltuely better in PL/I than COBOL (as I originally stated.  However, LE
>>callable services can handle most of what any COBOL application might ever 
>>WANT
>>to do.
>
> BIT strings and bit arrays are used in surveys where the answers are
> of the yes/no kind.  I was reminded of this by a recent event.
>
> Just a few weeks ago, while researching a first generation computer,
> I found that the input data was punched on cards, 12 answers per column,
> in 32 columns (giving 384 values per 80-column card).
> The data was held in storage as bit strings.
> LE callable services are not available to non-IBM platforms.
>
>>> 8.    VARYING character strings (two kinds: length determined, and
>>>       zero-terminated for compatibility with C);
>>"z-terminated" literals have been available in IBM COBOL for years.  "VARYING"
>>with prefixed length is also available - but the length is visible.
>
> You said that before.
>
>>  Most COBOL
>>(and possibly some other application) programmers would consider this an
>>advantage - but I am certainly willing to say it is a "design" decision.
>>Interestingly enough the currently under-development COBOL Standard is 
>>including
>>both of these types of "native" data-types.
>>
>>> 9.    Extensive string-handling fuinctions;
>> Some, but certainly not much available in PL/I that isn't already available 
>> in
>>COBOL.  Only "TRIM" has been misign and ANSI/ISO is adding that.  (STRING andf
>>UNSTRING statements in COBOL are as powerful as anything that I know of in
>>PL/I - but this may be my ignorance)
>>
>>> 10.    Data structures for commercial work; including BY NAME option;
>>I don't think that you could convince any COBOL site that there ALL the
>>"data-types" that they need for commercial processing.
>>
>>> 11.  Array handling;
>>Again, been in COBOL since the "beginnning" (unless you are talking about 
>>VECTOR
>>processing, which I admit isn't in COBOL -
>
> I'm referring to vector/matrix/multi-dimensional array handling,
> not table handling.
>
>> but rarely needed for "business data processing"
>
> Naturally, as it's not in COBOL, but nevertheless, it's still needed.
Then why do the majoirty of IBM mainframe shops not need it?
>
>>> 12.   Preprocessor;
>> Absolutely better in PL/I (and I included it in my original list)
>>
>>> 13.    Productivity.
>>Not only is this totally a matter of "what you are used to" - there are
>>significantly MORE 3rd party COBOL "productivity" tools than there are for 
>>PL/I
>>and this is NOT because you can't be productive in COBOL, but simply because 
>>of
>>its long standing popularity among IBM commercial data processing sites.
>
> I'm not referring to productivity tools.
> I'm referring PL/I as a language.
> The verbosity of COBOL works against it.

Again, a matter of opinikon. Your view doesn't seemt to predominate among those 
doing IBM amainframe business data processing.

>
>>> As well as these, not for commercial work, are:
>>>
>>> 14.    complex arithmetic;
>>> 15.    Improved list-processing facilities (I guess these could be used
>>>         for commercial work too);
>
> 


0
wmklein (2605)
9/18/2006 7:14:30 AM
Many of those don't need functions in COBOL because "non-Function" statements 
are already available - before COBOL supported intrinsic functions.  For the 
list of currently available Intrinsic Functions in Enterprise COBOL, check out:
  http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR31/CCONTENTS

Chapter:
   "7.1 Intrinsic functions" at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR31/7.1


-- 
Bill Klein
 wmklein <at> ix.netcom.com
"robin" <robin_v@bigpond.com> wrote in message 
news:9GqPg.30658$rP1.8218@news-server.bigpond.net.au...
> William M. Klein (wmklein <at> ix.netcom.com) wrote in message ...
>
>>"robin" <robin_v@bigpond.com> wrote in message
>>news:8dnOg.29059$rP1.14238@news-server.bigpond.net.au...
>
>>> 9.    Extensive string-handling functions;
>> Some, but certainly not much available in PL/I that isn't already available 
>> in
>>COBOL.  Only "TRIM" has been misign and ANSI/ISO is adding that.  (STRING andf
>>UNSTRING statements in COBOL are as powerful as anything that I know of in
>>PL/I - but this may be my ignorance)
>
> Just for the record, these and more are available in PL/I:-
>
> (BTW, strings available include CHARACTER, MIXED, GRAPHIC,
> WIDECHAR, and BIT)
>
> *    CHAR
> *    STRING
> *    UNSPEC
> *    SEARCH
> *    SEARCHR (search in reverse)
> *    VERIFY
> *    VERIFYR (verify in reverse)
> *    INDEX
> *    TRANSLATE
> *    LEFT
> *    RIGHT
> *    CENTER
> *    CENTERRIGHT, CENTERLEFT
> *    TRIM (mainly used for removing blanks from the beginning and/or end
>      of a string, but is also used for removing any combination of characters
>      from either or both ends of a string.  It's like a combinarion of VERIFY,
>      VERIFYR, and SUBSTR).
> *    LENGTH
> *    MAXLENGTH
> *    LOWERCASE returns the lower-case version of the string argument.
> *    UPPERCASE returns the upper-case version of the string argument.
> *    PLIDUMP produces a formatted dump of storage used by the program.
> *    PLISAXA and PLISAXB invoke the high-speed XML parser.
>    PLISAXA process an XML document held in memory,
>    while PLISAXB processes a file of XML data.
>    Supports 21 EBCDIC code pages and 3 ASCII code pages.
> *    BITLOCATION(x) returns the location (in the range 0 to 7) of x
>     within the byte where x is stored. (x is UNALIGNED BIT.)
> *    CURRENTSIZE returns the number of bytes
>     in a variable or structure.
> *    EDIT(Value, picture_pattern) returns Value in the form
>     specified by the picture pattern.
>     e.g., EDIT (12.345, '9999.999') returns '0012.345'
> *    HEX returns the hexadecimal form of the character string
>     argument. HEX('abc') returns '616263' on an ASCII machine,
>     and '818283' on an EBCDIC machine. HEX(S, ' ') is the same
>     as HEX(S), except that blanks are inserted in the returned
>     hexadecimal string - after every eighth character.
> *    HEXIMAGE is like HEX. HEXIMAGE(S, n) returns n characters
>     at the address S (as a hexadecial string).
> *    HEXIMAGE(S, n, c) is the same as HEXIMAGE(S, n)
>     except that the character c is inserted after every eighth character
>     of the hexadecimal string.
> *    TALLY(S, T) counts the number of times that string T appears
>     in string S.
> *    MEMINDEX is like INDEX.
> *    MEMSEARCH is like SEARCH.
> *    MEMSEARCH (b, k, key)
> *    MEMSEARCH
> *    MEMSEARCHR is the same as MEMSEARCH, except that
>     the search is backwards
> *    MEMVERIFY is like VERIFY
> *    MEMVERIFY
> *    MEMSEARCH
> *    MEMVERIFYR is the same as MEMVERIFY except that the
>     search is backwards
> *    REPLACEBY2 is like TRANSLATE. Usage:
>     REPLACEBY2 (string, rep, original) searches a copy of string.
>     If a character in <original> exists in <string>, the corresponding
>     pair of characters in <rep> are substituted.
> *    XMLCHAR for handling XML strings.
> *    BIT
> *    COLLATE
> *    REPATTERN (for transforming a date into a convenient
>      printable form).
> *    RANK
> *    SUBSTR
> *    ONCHAR
> *    ONSOURCE
> Plus similar ON- functions for GRAPHIC and WIDECHAR.
>
> 


0
wmklein (2605)
9/18/2006 7:18:07 AM
William M. Klein wrote:
 > Anyone who doesn't consider LE part of the COBOL language should
 > show a run  of currently supported PL/I *without* LE.  It *is* part 
of > the IBM mainframe language.

I have to disagree, LE isn't part of *any* language, it's non-standard 
and proprietary.  A lot of the features it provides are handy, and in 
several cases it introduces unnecessary restrictions.

My feeling is that the run-time part of it should have been better 
integrated into the respective languages instead of being a separate set 
of "LE" calls, and the rest should have been a separate package.  DEC 
did it better years ago, and it was much more transparent to programmers.

0
Peter_Flass (956)
9/18/2006 10:35:35 AM
On Mon, 18 Sep 2006 03:35:35 -0700, Peter Flass <Peter_Flass@Yahoo.com>  
wrote:

> William M. Klein wrote:
>  > Anyone who doesn't consider LE part of the COBOL language should
>  > show a run  of currently supported PL/I *without* LE.  It *is* part  
> of > the IBM mainframe language.
>
> I have to disagree, LE isn't part of *any* language, it's non-standard  
> and proprietary.  A lot of the features it provides are handy, and in  
> several cases it introduces unnecessary restrictions.
>
> My feeling is that the run-time part of it should have been better  
> integrated into the respective languages instead of being a separate set  
> of "LE" calls, and the rest should have been a separate package.  DEC  
> did it better years ago, and it was much more transparent to programmers.
>
We are currently rewriting the Bliss portions od SDL in PL/I and so it
should be easier to port.  Stay tuned.


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/18/2006 1:28:03 PM
Peter Flass <Peter_Flass@yahoo.com> wrote:
> William M. Klein wrote:
> > Anyone who doesn't consider LE part of the COBOL language should
> > show a run  of currently supported PL/I *without* LE.  It *is* part 
> of > the IBM mainframe language.
 
> I have to disagree, LE isn't part of *any* language, it's non-standard 
> and proprietary.  A lot of the features it provides are handy, and in 
> several cases it introduces unnecessary restrictions.

While not part of any language, I always thought it was primarily
for C, with the others along for the ride.  Note the three letter
prefix for LE modules.

-- glen
0
gah1 (524)
9/18/2006 5:58:34 PM
Peter,
   You have taken my quote out of context.  LE *is* part of the IBM mainframe 
PL/I environment.  Whether it should or should not have been, you simply cannot 
USE IBM PL/I on an IBM mainframe (today) without it.  All the callable services 
ARE available - as is the LE condition handling (and allocation) facilities and 
the run-time settings.

It is 100% true that you CAN use PL/I "native" syntax to do things that, in 
COBOL, require LE callable services, but that doesn't mean that the native 
syntax is the only way to do it in PL/I, nor that the CALL interface isn't part 
of the COBOL environment (again, on IBM mainframes).

P.S.  I don't know how many readers of comp.lang.pl1 were part of the SHARE or 
GUIDE (US or elsewhere) sessions talking about "condition handling" in (what 
became) LE before LE was first introduced, but there was a LOT of discussion 
about using the "PL/I" model or the "C" model as opposed to introducing a 
(slightly incompatible) new condition handling model.  I still have (some) 
issues with how LE does handle conditions in a multi-language environment, but 
it is pretty stable and is certainly universally available in IBM mainframe 
shops.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
news:XDuPg.42816$xV.33420@twister.nyroc.rr.com...
> William M. Klein wrote:
> > Anyone who doesn't consider LE part of the COBOL language should
> > show a run  of currently supported PL/I *without* LE.  It *is* part
> of > the IBM mainframe language.
>
> I have to disagree, LE isn't part of *any* language, it's non-standard and 
> proprietary.  A lot of the features it provides are handy, and in several 
> cases it introduces unnecessary restrictions.
>
> My feeling is that the run-time part of it should have been better integrated 
> into the respective languages instead of being a separate set of "LE" calls, 
> and the rest should have been a separate package.  DEC did it better years 
> ago, and it was much more transparent to programmers.
> 


0
wmklein (2605)
9/18/2006 6:34:16 PM
"C" in "CEE" stands for "Common" (as does the "C" in COBOL <G>)

 - CEE = "Common Execution Environment"\
 - CEL = "Common Execution Library"

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"glen herrmannsfeldt" <gah@seniti.ugcs.caltech.edu> wrote in message 
news:eemmoa$hjd$6@naig.caltech.edu...
> Peter Flass <Peter_Flass@yahoo.com> wrote:
>> William M. Klein wrote:
>> > Anyone who doesn't consider LE part of the COBOL language should
>> > show a run  of currently supported PL/I *without* LE.  It *is* part
>> of > the IBM mainframe language.
>
>> I have to disagree, LE isn't part of *any* language, it's non-standard
>> and proprietary.  A lot of the features it provides are handy, and in
>> several cases it introduces unnecessary restrictions.
>
> While not part of any language, I always thought it was primarily
> for C, with the others along for the ride.  Note the three letter
> prefix for LE modules.
>
> -- glen 


0
wmklein (2605)
9/18/2006 6:36:08 PM
William M. Klein <wmklein@nospam.netcom.com> wrote:
> "C" in "CEE" stands for "Common" (as does the "C" in COBOL <G>)
> 
> - CEE = "Common Execution Environment"\
> - CEL = "Common Execution Library"

So that is what it stands for.

My favorite name for a directory where I store my C programs
is cees, which may be why I thought CEE was related to C.

Also, because I first knew about it around the time I knew
of an IBM C compiler.

thanks,

-- glen
0
gah1 (524)
9/18/2006 6:55:59 PM
On Mon, 18 Sep 2006 11:34:16 -0700, William M. Klein  
<wmklein@nospam.netcom.com> wrote:

> Peter,
>    You have taken my quote out of context.  LE *is* part of the IBM  
> mainframe
> PL/I environment.  Whether it should or should not have been, you simply  
> cannot
> USE IBM PL/I on an IBM mainframe (today) without it.  All the callable  
> services
> ARE available - as is the LE condition handling (and allocation)  
> facilities and
> the run-time settings.

Does IBM provide language specific include files with declarations for
entry points, globals and sundry?

>
> It is 100% true that you CAN use PL/I "native" syntax to do things that,  
> in
> COBOL, require LE callable services, but that doesn't mean that the  
> native
> syntax is the only way to do it in PL/I, nor that the CALL interface  
> isn't part
> of the COBOL environment (again, on IBM mainframes).
>
> P.S.  I don't know how many readers of comp.lang.pl1 were part of the  
> SHARE or
> GUIDE (US or elsewhere) sessions talking about "condition handling" in  
> (what
> became) LE before LE was first introduced, but there was a LOT of  
> discussion
> about using the "PL/I" model or the "C" model as opposed to introducing a
> (slightly incompatible) new condition handling model.  I still have  
> (some)
> issues with how LE does handle conditions in a multi-language  
> environment, but
> it is pretty stable and is certainly universally available in IBM  
> mainframe
> shops.
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
0
tom294 (608)
9/18/2006 7:58:13 PM
glen herrmannsfeldt wrote:
> Peter Flass <Peter_Flass@yahoo.com> wrote:
>> William M. Klein wrote:
>>> Anyone who doesn't consider LE part of the COBOL language should
>>> show a run  of currently supported PL/I *without* LE.  It *is* part 
>> of > the IBM mainframe language.
>  
>> I have to disagree, LE isn't part of *any* language, it's non-standard 
>> and proprietary.  A lot of the features it provides are handy, and in 
>> several cases it introduces unnecessary restrictions.
> 
> While not part of any language, I always thought it was primarily
> for C, with the others along for the ride.  Note the three letter
> prefix for LE modules.

It was historically developed for exclusive use by PL/I, then extended 
to C, and then to other languages.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
9/18/2006 8:09:20 PM
Huh?  What are we talking about.

As far as LE goes, the first two languages supported were C and COBOL.  I can't 
remember if PL/I was added in Release 2 or 3.

As far as "CEE" goes, it is ONLY valid as a prefix for LE modules.

What were you talking about that was first available in PL/I and then C and then 
other languages?  (I can think of some things that this might be true of, but 
don't know what YOU are talking about)

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message 
news:R1DPg.28$YZ2.17@newsfe10.lga...
> glen herrmannsfeldt wrote:
>> Peter Flass <Peter_Flass@yahoo.com> wrote:
>>> William M. Klein wrote:
>>>> Anyone who doesn't consider LE part of the COBOL language should
>>>> show a run  of currently supported PL/I *without* LE.  It *is* part
>>> of > the IBM mainframe language.
>>
>>> I have to disagree, LE isn't part of *any* language, it's non-standard and 
>>> proprietary.  A lot of the features it provides are handy, and in several 
>>> cases it introduces unnecessary restrictions.
>>
>> While not part of any language, I always thought it was primarily
>> for C, with the others along for the ride.  Note the three letter
>> prefix for LE modules.
>
> It was historically developed for exclusive use by PL/I, then extended to C, 
> and then to other languages.
>
> -- 
> John W. Kennedy
> "The blind rulers of Logres
> Nourished the land on a fallacy of rational virtue."
>   -- Charles Williams.  "Taliessin through Logres: Prelude" 


0
wmklein (2605)
9/18/2006 8:35:05 PM
John W. Kennedy <jwkenne@attglobal.net> wrote:
(snip regarding library name prefixes)
 
>> While not part of any language, I always thought it was primarily
>> for C, with the others along for the ride.  Note the three letter
>> prefix for LE modules.
 
> It was historically developed for exclusive use by PL/I, then extended 
> to C, and then to other languages.

That is what I would have thought, except for the name and when
I first learned about it.  

Note also the prefix for the previous PL/I library: IBM.
That always seemed significant to me, too.

-- glen 
0
gah1 (524)
9/18/2006 9:04:45 PM
Tom Linden <tom@kednos-remove.com> wrote:
 
> Does IBM provide language specific include files with declarations for
> entry points, globals and sundry?

I used to know some Assembler/PL/I combined include files using
careful commenting such that only the appropriate lines were seen by
each language.  

-- glne
0
gah1 (524)
9/18/2006 9:07:28 PM
Yes, IBM includes "language specific" include files (or COPYBOOKS for COBOL) for 
LE.  See:
   http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea3170/2.2.3.1

They also include "sample" programs using all the callable services in each of 
the languages.  See for example,
  http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA3170/2.2.5.64.3
(These examples are all provided in machine readable format with the LE 
software)

for how to "signal a condition" in C/C++, COBOL, and PL/I *not* using "native" 
syntax but LE callable services.


-- 
Bill Klein
 wmklein <at> ix.netcom.com
"glen herrmannsfeldt" <gah@seniti.ugcs.caltech.edu> wrote in message 
news:een1qg$lol$3@naig.caltech.edu...
> Tom Linden <tom@kednos-remove.com> wrote:
>
>> Does IBM provide language specific include files with declarations for
>> entry points, globals and sundry?
>
> I used to know some Assembler/PL/I combined include files using
> careful commenting such that only the appropriate lines were seen by
> each language.
>
> -- glne 


0
wmklein (2605)
9/18/2006 9:27:06 PM
Tom Linden wrote:
> We are currently rewriting the Bliss portions od SDL in PL/I and so it
> should be easier to port.  Stay tuned.
> 
Not relevant to this thread (unless the mention of DEC  qualifies), but 
very good news nonetheless.  Thanks, Tom!

0
Peter_Flass (956)
9/18/2006 9:41:50 PM
William M. Klein wrote:

> Peter,
>    You have taken my quote out of context.  LE *is* part of the IBM mainframe 
> PL/I environment.  Whether it should or should not have been, you simply cannot 
> USE IBM PL/I on an IBM mainframe (today) without it.  All the callable services 
> ARE available - as is the LE condition handling (and allocation) facilities and 
> the run-time settings.

Sorry :-(

> 
> It is 100% true that you CAN use PL/I "native" syntax to do things that, in 
> COBOL, require LE callable services, but that doesn't mean that the native 
> syntax is the only way to do it in PL/I, nor that the CALL interface isn't part 
> of the COBOL environment (again, on IBM mainframes).
> 
> P.S.  I don't know how many readers of comp.lang.pl1 were part of the SHARE or 
> GUIDE (US or elsewhere) sessions talking about "condition handling" in (what 
> became) LE before LE was first introduced, but there was a LOT of discussion 
> about using the "PL/I" model or the "C" model as opposed to introducing a 
> (slightly incompatible) new condition handling model.  I still have (some) 
> issues with how LE does handle conditions in a multi-language environment, but 
> it is pretty stable and is certainly universally available in IBM mainframe 
> shops.
> 

It seems better.  For one of the early releases I installed, I recall I 
had to set the "condition limit" to zero, or whatever, to get condition 
handling to work properly.  IOW, some error, possibly a hardware 
overflow or underflow, that was getting trapped to LE, which then 
checked the PL/I condition settings to determine what to do with it. 
This blew my mind because I have some idea of the overhead involved in 
processing a (unnecessary) hardware interrupt.  I believe they fixed 
this in a later release.

0
Peter_Flass (956)
9/18/2006 9:46:45 PM
Peter Flass <Peter_Flass@yahoo.com> wrote:
(snip)
 
> It seems better.  For one of the early releases I installed, I recall I 
> had to set the "condition limit" to zero, or whatever, to get condition 
> handling to work properly.  IOW, some error, possibly a hardware 
> overflow or underflow, that was getting trapped to LE, which then 
> checked the PL/I condition settings to determine what to do with it. 

I thought that was the whole idea for SPM. (set program mask)
Also, why PL/I has the exceptions that it does have, because
those are the ones supported by S/360 hardware.  (Though SIZE
isn't all that well supported, and is known to be slow.)

-- glen
0
gah1 (524)
9/18/2006 10:20:36 PM
William M. Klein wrote:
> Huh?  What are we talking about.
> 
> As far as LE goes, the first two languages supported were C and COBOL.  I can't 
> remember if PL/I was added in Release 2 or 3.
> 
> As far as "CEE" goes, it is ONLY valid as a prefix for LE modules.
> 
> What were you talking about that was first available in PL/I and then C and then 
> other languages?  (I can think of some things that this might be true of, but 
> don't know what YOU are talking about)

I'm not sure when the /name/ "LE" came in, but the thing itself first 
came into the world in 1971 as the run-time library of the PL/I 
Optimizing Compiler. Then support of the C compiler was added. Then more.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
9/18/2006 10:37:30 PM
glen herrmannsfeldt wrote:
> I thought that was the whole idea for SPM. (set program mask)

 From the very start, the OS/360 designers decided that use of SPM by 
the application programmer was naughty, and asked programmers to use 
SPIE instead. (In OS/360, SPIE took a fairly fast ad-hoc path through 
the nucleus, so the overhead wasn't too bad; adding support of virtual 
memory made it much more expensive.)

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
9/18/2006 10:41:44 PM
I still don't know what you think came in in 1971.  Are you saying a "run-time 
library"?  COBOL certainly supported "RES and NORES" about that time (but 
possibly later).  If you are saying the "base code" for what is currently 
provided in the LE run-time library, then there ARE parts of it that still have 
"IBM" prefixes that are PL/I specific - just as there are parts that have IGY 
prefixes and are COBOL-specific.

Again, what exactly are you saying was "introduced in 1971" first for PL/I (then 
for C then for other languages).

If you are talking about "ILC" (inter-language communication), the major 
motivation for introducing LE was that ILC was AWFUL as defined in PL/I, COBOL, 
and C before the LE-specific product (then part of the operating system) were 
introduced.  Yes, it existed, but each language did it differently and I don't 
know of ANY programmer who was happy with how it was done.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message 
news:McFPg.42$cC4.0@newsfe11.lga...
> William M. Klein wrote:
>> Huh?  What are we talking about.
>>
>> As far as LE goes, the first two languages supported were C and COBOL.  I 
>> can't remember if PL/I was added in Release 2 or 3.
>>
>> As far as "CEE" goes, it is ONLY valid as a prefix for LE modules.
>>
>> What were you talking about that was first available in PL/I and then C and 
>> then other languages?  (I can think of some things that this might be true 
>> of, but don't know what YOU are talking about)
>
> I'm not sure when the /name/ "LE" came in, but the thing itself first came 
> into the world in 1971 as the run-time library of the PL/I Optimizing 
> Compiler. Then support of the C compiler was added. Then more.
>
> -- 
> John W. Kennedy
> "The blind rulers of Logres
> Nourished the land on a fallacy of rational virtue."
>   -- Charles Williams.  "Taliessin through Logres: Prelude" 


0
wmklein (2605)
9/18/2006 10:55:56 PM
William M. Klein wrote in message ...
> wmklein <at> ix.netcom.com
>"robin" <robin_v@bigpond.com> wrote in message
>news:8GqPg.30657$rP1.17975@news-server.bigpond.net.au...
>> William M. Klein wrote in message ...
>>>I was (sort-of with you until your last statement, but let's look at 1-13 for
>>>today's IBM mainframe COBOL environment (which is all I was asking about)
>>>
>>>--
>>>Bill Klein
>>> wmklein <at> ix.netcom.com
>>>"robin" <robin_v@bigpond.com> wrote in message
>>>news:8dnOg.29059$rP1.14238@news-server.bigpond.net.au...
>>>> William M. Klein wrote in message ...
>>>>>"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
>>>>>news:v6kNg.243$W02.66@newsfe08.lga...
>>>>>> adaworks@sbcglobal.net wrote:

>>>> 2.    Error control, and consequent ease of recovery;
>>> On an IBM mainframe, full LE condition handling is available (along with
>>>traditional COBOL declaratives)
>>
>> I'm not referring to LE handling.
>> I'm referring to what's available in PL/I.
>
>How do you run PL/I "error handling" without USING LE for the run-time?
> CALL is part of COBOL so it LE condition handling is part of IBM mainframe
>COBOL.

PL/I doesn't need LE to run.
I do not use LE run-time.


0
robin_v (2737)
9/19/2006 1:12:11 AM
William M. Klein wrote in message ...
> wmklein <at> ix.netcom.com
>"robin" <robin_v@bigpond.com> wrote in message
>news:8GqPg.30657$rP1.17975@news-server.bigpond.net.au...

>>>> 6.    A DATE data type, and automatic handling of 2 and 4-digit years
>>>>        with century windowing; [COBOL too]
>>> For IBM mainframes, this has been available since within 12 months of when
>>> PL/I got it.
>>
>> I did mention that COBOL had it too.
> So why is it listed in "1-13"
>>
>>> (4/2 year date handling is also portable now that it is included in the
>>>ANSI/ISO Standard - but admittedly DATE data-types are not.)
>>
>> Then how are mixed 2-digit years and 4-digit years handled automatically?
> Thru "Millentium Language Extensions"

So they are not part of COBOL?

Perhaps you would explain how a date can be automatically
recognized and converted from 2-digit year to 4-digit form
and vice versa when there's no DATE type?

In PL/I, the construct
IF D1 > D2 THEN ...

is recognized as a comparison between a 2-digit year and a 4-digit year
(assume that D1 contains a 2-digit year, and D2 contains a 4-digit year),
and the 2-digit year form is automatically converted to 4-digit year form
for the comparison.


0
robin_v (2737)
9/19/2006 1:12:12 AM
William M. Klein wrote in message ...
> wmklein <at> ix.netcom.com
>"robin" <robin_v@bigpond.com> wrote in message
>news:8dnOg.29059$rP1.14238@news-server.bigpond.net.au...
>> William M. Klein wrote in message ...
>> 13.    Productivity.
>Not only is this totally a matter of "what you are used to" - there are
>significantly MORE 3rd party COBOL "productivity" tools than there are for PL/I
>and this is NOT because you can't be productive in COBOL, but simply because of
>its long standing popularity among IBM commercial data processing sites.

In general,. the existence of "productivity tools" - 3rd party or otherwise -
arises because of a deficiency/deficiencies in the language itself.

PL/I is self-contained in that it has the productivity tools built in.


0
robin_v (2737)
9/19/2006 1:12:12 AM
William M. Klein wrote in message ...
> wmklein <at> ix.netcom.com
>"robin" <robin_v@bigpond.com> wrote in message
>news:8GqPg.30657$rP1.17975@news-server.bigpond.net.au...
>> William M. Klein wrote in message ...

>>>> 5.    Comprehensive functions for decimal arithmetic;
>>>Ain't nothing in PL/I that hasn't been in COBOL since day 1 (before the
>>>beginning of PL/I)
>>
>> Except COMPLEX, conversions between BIT and DECIMAL,
>> and probably more.
>  What does "COMPLEX" and "BIT" have to with DECIMAL?  (I agree that PL/I has
>support for BIT and COMPLEX not available in COBOL.  See my original note.  -

In PL/I, decimal values can be COMPLEX.

I thought I made it clear in my statement [quoted below] about surveys
that BIT variables can be used for holding yes/no answers.

BIT values in PL/I may be converted to decimal,
and vice versa

> Just a few weeks ago, while researching a first generation computer,
> I found that the input data was punched on cards, 12 answers per column,
> in 32 columns (giving 384 values per 80-column card).
> The data was held in storage as bit strings.


0
robin_v (2737)
9/19/2006 1:12:13 AM
William M. Klein wrote in message ...
> wmklein <at> ix.netcom.com
>"robin" <robin_v@bigpond.com> wrote in message
>news:8GqPg.30657$rP1.17975@news-server.bigpond.net.au...
>> William M. Klein wrote in message ...

>>>> 11.  Array handling;
>>>Again, been in COBOL since the "beginnning" (unless you are talking about
>>>VECTOR
>>>processing, which I admit isn't in COBOL -
>>
>> I'm referring to vector/matrix/multi-dimensional array handling,
>> not table handling.
>>
>>> but rarely needed for "business data processing"
>>
>> Naturally, as it's not in COBOL, but nevertheless, it's still needed.
>Then why do the majoirty of IBM mainframe shops not need it?

If the language doesn't have the facility, then - obviously - programmers
can't use it.
The facility was put in PL/I because it was important for commercial
programmers.


0
robin_v (2737)
9/19/2006 1:12:14 AM
William M. Klein wrote in message ...
> wmklein <at> ix.netcom.com
>"robin" <robin_v@bigpond.com> wrote in message
>news:8GqPg.30657$rP1.17975@news-server.bigpond.net.au...
>> William M. Klein wrote in message ...
>>> wmklein <at> ix.netcom.com
>>>"robin" <robin_v@bigpond.com> wrote in message
>>>news:8dnOg.29059$rP1.14238@news-server.bigpond.net.au...

>>>> 4.    Suitability for large projects (an outcome of (2) and (3) above);
>>> If more "larger projects" are (and have been) done in COBOL than in PL/I, why
>>>do you think this is? I think this statement is simply a "what you are used
>>>to -
>>>is what is best for you" situation.
>>
>> Your response doesn't change the fact that PL/I is more suitable.
>  Based on what FACT?  (otrher than your opinion)  Certainly NOT based on
>"independent" mangagement decisions at the MAJORITY of IBM mainframe shops.

We all know about "management decisions".
They are protecting their own empires and are intent in
consolidating their position in the firm.

In any case, COBOL isn't restricted to IBM shops.


0
robin_v (2737)
9/19/2006 1:12:15 AM
William M. Klein wrote in message ...
>Many of those don't need functions in COBOL because "non-Function" statements
>are already available - before COBOL supported intrinsic functions.  For the
>list of currently available Intrinsic Functions in Enterprise COBOL, check out:
>  http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR31/CCONTENTS
>
>Chapter:
>   "7.1 Intrinsic functions" at:
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR31/7.1


Is this all there is, then? :-
7.1.9 ACOS
7.1.10 ANNUITY
7.1.11 ASIN
7.1.12 ATAN
7.1.13 CHAR
7.1.14 COS
7.1.15 CURRENT-DATE
7.1.16 DATE-OF-INTEGER
7.1.17 DATE-TO-YYYYMMDD
7.1.18 DATEVAL
7.1.19 DAY-OF-INTEGER
7.1.20 DAY-TO-YYYYDDD
7.1.21 DISPLAY-OF
7.1.22 FACTORIAL
7.1.23 INTEGER
7.1.24 INTEGER-OF-DATE
7.1.25 INTEGER-OF-DAY
7.1.26 INTEGER-PART
7.1.27 LENGTH
7.1.28 LOG
7.1.29 LOG10
7.1.30 LOWER-CASE
7.1.31 MAX
7.1.32 MEAN
7.1.33 MEDIAN
7.1.34 MIDRANGE
7.1.35 MIN
7.1.36 MOD
7.1.37 NATIONAL-OF
7.1.38 NUMVAL
7.1.39 NUMVAL-C
7.1.40 ORD
7.1.41 ORD-MAX
7.1.42 ORD-MIN
7.1.43 PRESENT-VALUE
7.1.44 RANDOM
7.1.45 RANGE
7.1.46 REM
7.1.47 REVERSE
7.1.48 SIN
7.1.49 SQRT
7.1.50 STANDARD-DEVIATION
7.1.51 SUM
7.1.52 TAN
7.1.53 UNDATE
7.1.54 UPPER-CASE
7.1.55 VARIANCE
7.1.56 WHEN-COMPILED
7.1.57 YEAR-TO-YYYY
7.1.58 YEARWINDOW


0
robin_v (2737)
9/19/2006 1:17:14 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:LtHPg.31089$rP1.12790@news-server.bigpond.net.au...
> William M. Klein wrote in message ...
>> wmklein <at> ix.netcom.com
<snip>
>>How do you run PL/I "error handling" without USING LE for the run-time?
>> CALL is part of COBOL so it LE condition handling is part of IBM mainframe
>>COBOL.
>
> PL/I doesn't need LE to run.
> I do not use LE run-time.
>
>

On an IBM mainframe?  (Certainly not with any supported IBM PL/I compiler).  If 
you do can you provide some more information on HOW? 


0
wmklein (2605)
9/19/2006 1:30:18 AM
The reason in COBOL's case, is that the USE of COBOL in IBM mainframe shops is 
so prevalent, that the market will SUPPORT selling almost anything.  If you can 
provide an example of something that is available in PL/I for "business data 
processing" that is NOT available in COBOL (for productivity purposes) without 
3rd party products, then I would be interested in what it is.

As far as tools available for IBM Pl/I mainframe application development, they 
certainly DO exist including
 - 3rd party debugging tools - static and interactive)
 - load module analysis tools (such as Edge Portfolio Analyzer)
 - "Application generators" such as Telcon (and I think Pacbase also has a PL/I 
generator option)
 - Revolve "data flow analyzer"
 - and others

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"robin" <robin_v@bigpond.com> wrote in message 
news:MtHPg.31091$rP1.8399@news-server.bigpond.net.au...
> William M. Klein wrote in message ...
>> wmklein <at> ix.netcom.com
>>"robin" <robin_v@bigpond.com> wrote in message
>>news:8dnOg.29059$rP1.14238@news-server.bigpond.net.au...
>>> William M. Klein wrote in message ...
>>> 13.    Productivity.
>>Not only is this totally a matter of "what you are used to" - there are
>>significantly MORE 3rd party COBOL "productivity" tools than there are for 
>>PL/I
>>and this is NOT because you can't be productive in COBOL, but simply because 
>>of
>>its long standing popularity among IBM commercial data processing sites.
>
> In general,. the existence of "productivity tools" - 3rd party or otherwise -
> arises because of a deficiency/deficiencies in the language itself.
>
> PL/I is self-contained in that it has the productivity tools built in.
>
> 


0
wmklein (2605)
9/19/2006 1:34:05 AM
The "millennium language extensions" have been a built-in part of the COBOL 
compiler since ABOUT 9 months after they were available in the IBM PL/I 
compiler.  These DO include "date" data types.  For more information on these, 
see:

 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3lr31/1.10.1

and

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg31/7.2.1


-- 
Bill Klein
 wmklein <at> ix.netcom.com
"robin" <robin_v@bigpond.com> wrote in message 
news:MtHPg.31090$rP1.22874@news-server.bigpond.net.au...
> William M. Klein wrote in message ...
>> wmklein <at> ix.netcom.com
>>"robin" <robin_v@bigpond.com> wrote in message
>>news:8GqPg.30657$rP1.17975@news-server.bigpond.net.au...
>
>>>>> 6.    A DATE data type, and automatic handling of 2 and 4-digit years
>>>>>        with century windowing; [COBOL too]
>>>> For IBM mainframes, this has been available since within 12 months of when
>>>> PL/I got it.
>>>
>>> I did mention that COBOL had it too.
>> So why is it listed in "1-13"
>>>
>>>> (4/2 year date handling is also portable now that it is included in the
>>>>ANSI/ISO Standard - but admittedly DATE data-types are not.)
>>>
>>> Then how are mixed 2-digit years and 4-digit years handled automatically?
>> Thru "Millentium Language Extensions"
>
> So they are not part of COBOL?
>
> Perhaps you would explain how a date can be automatically
> recognized and converted from 2-digit year to 4-digit form
> and vice versa when there's no DATE type?
>
> In PL/I, the construct
> IF D1 > D2 THEN ...
>
> is recognized as a comparison between a 2-digit year and a 4-digit year
> (assume that D1 contains a 2-digit year, and D2 contains a 4-digit year),
> and the 2-digit year form is automatically converted to 4-digit year form
> for the comparison.
>
> 


0
wmklein (2605)
9/19/2006 1:37:21 AM
Certainly "bit fields" can be used in business data processing.  I just haven't 
experienced any applications that REQUIRED them - at least not currently.  Any 
application that relies on a "punch card format" is NOT what I would 
(personally) consider a "current data processing" application.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"robin" <robin_v@bigpond.com> wrote in message 
news:NtHPg.31092$rP1.7354@news-server.bigpond.net.au...
> William M. Klein wrote in message ...
>> wmklein <at> ix.netcom.com
>>"robin" <robin_v@bigpond.com> wrote in message
>>news:8GqPg.30657$rP1.17975@news-server.bigpond.net.au...
>>> William M. Klein wrote in message ...
>
>>>>> 5.    Comprehensive functions for decimal arithmetic;
>>>>Ain't nothing in PL/I that hasn't been in COBOL since day 1 (before the
>>>>beginning of PL/I)
>>>
>>> Except COMPLEX, conversions between BIT and DECIMAL,
>>> and probably more.
>>  What does "COMPLEX" and "BIT" have to with DECIMAL?  (I agree that PL/I has
>>support for BIT and COMPLEX not available in COBOL.  See my original note.  -
>
> In PL/I, decimal values can be COMPLEX.
>
> I thought I made it clear in my statement [quoted below] about surveys
> that BIT variables can be used for holding yes/no answers.
>
> BIT values in PL/I may be converted to decimal,
> and vice versa
>
>> Just a few weeks ago, while researching a first generation computer,
>> I found that the input data was punched on cards, 12 answers per column,
>> in 32 columns (giving 384 values per 80-column card).
>> The data was held in storage as bit strings.
>
> 


0
wmklein (2605)
9/19/2006 1:39:03 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:OtHPg.31093$rP1.30566@news-server.bigpond.net.au...
> William M. Klein wrote in message ...
>> wmklein <at> ix.netcom.com
>>"robin" <robin_v@bigpond.com> wrote in message
>>news:8GqPg.30657$rP1.17975@news-server.bigpond.net.au...
<snip>
>>> Naturally, as it's not in COBOL, but nevertheless, it's still needed.
>>Then why do the majoirty of IBM mainframe shops not need it?
>
> If the language doesn't have the facility, then - obviously - programmers
> can't use it.
> The facility was put in PL/I because it was important for commercial
> programmers.
>

And your evidence for this being true is what?  Certainly, the need is their for 
SCIENTIFIC data processing and that is a need that PL/I was originally designed 
for.

Can you point to any IBM mainframe shop or application that found that they HAD 
to use PL/I because COBOL couldn't do this for "commercial data processing"?



-- 
Bill Klein
 wmklein <at> ix.netcom.com 


0
wmklein (2605)
9/19/2006 1:40:51 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:PtHPg.31094$rP1.8422@news-server.bigpond.net.au...
> William M. Klein wrote in message ...
<snip>
>>> Your response doesn't change the fact that PL/I is more suitable.
>>  Based on what FACT?  (otrher than your opinion)  Certainly NOT based on
>>"independent" mangagement decisions at the MAJORITY of IBM mainframe shops.
>
> We all know about "management decisions".
> They are protecting their own empires and are intent in
> consolidating their position in the firm.
>
> In any case, COBOL isn't restricted to IBM shops.
>
>

Absolutely true.  Neither COBOL nor PL/I is limited to IBM shops.  The fact that 
COBOL is MUCH more common in IBM "OS/400" than PL/I (but not as common as RPG) 
doesn't say a lot about whether or not PL/I has or doesn't have advantages over 
COBOL for IBM mainframe business application design and implementation (the only 
thing that I was addressing originally).  In fact, the fact that there are at 
least two commercial .NET COBOL products (for Microsoft .NET environments) and 
ZERO PL/I commercial compilers (that I am aware of) for that same environment, 
also doesn't address my original point.

HOWEVER, the fact that management at IBM mainframe "business" sites have NOT 
found a need to move from COBOL to PL/I does seem (to me) to indicate that there 
simply are NOT any significant advantages to PL/I to justify such a move.  There 
have been (especially in the last few years) a number of IBM mainframe shops 
moving from PL/I to COBOL - not because of technical deficiencies in the 
language - but simply based on the supply of programmers and software.  This 
actually IS a reverse of what was happening in the late '70s and early 80's when 
there was a movement from PL/I to COBOL.  This was before the '85 Standard of 
COBOL added certain features and also before IBM gave its VERY mixed signal by 
NOT including PL/I in the initial  (now long dead and NOT missed) SAA 
specification, when it did include COBOL, C, (and Fortran and I think even RPG).

-- 
Bill Klein
 wmklein <at> ix.netcom.com 


0
wmklein (2605)
9/19/2006 1:47:54 AM
If this is what they list, then yes.  As I indicated before, there are things 
that PL/I uses functions for that COBOL uses syntax for.  (For example the 
recently added to both XML support).  Obvious other items include things like 
the PL/I SEARCH and SEARCHR functions, PLIDUMP, EDIT, etc.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"robin" <robin_v@bigpond.com> wrote in message 
news:uyHPg.31096$rP1.14960@news-server.bigpond.net.au...
> William M. Klein wrote in message ...
>>Many of those don't need functions in COBOL because "non-Function" statements
>>are already available - before COBOL supported intrinsic functions.  For the
>>list of currently available Intrinsic Functions in Enterprise COBOL, check 
>>out:
>> 
>> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR31/CCONTENTS
>>
>>Chapter:
>>   "7.1 Intrinsic functions" at:
>>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR31/7.1
>
>
> Is this all there is, then? :-
> 7.1.9 ACOS
> 7.1.10 ANNUITY
> 7.1.11 ASIN
> 7.1.12 ATAN
> 7.1.13 CHAR
> 7.1.14 COS
> 7.1.15 CURRENT-DATE
> 7.1.16 DATE-OF-INTEGER
> 7.1.17 DATE-TO-YYYYMMDD
> 7.1.18 DATEVAL
> 7.1.19 DAY-OF-INTEGER
> 7.1.20 DAY-TO-YYYYDDD
> 7.1.21 DISPLAY-OF
> 7.1.22 FACTORIAL
> 7.1.23 INTEGER
> 7.1.24 INTEGER-OF-DATE
> 7.1.25 INTEGER-OF-DAY
> 7.1.26 INTEGER-PART
> 7.1.27 LENGTH
> 7.1.28 LOG
> 7.1.29 LOG10
> 7.1.30 LOWER-CASE
> 7.1.31 MAX
> 7.1.32 MEAN
> 7.1.33 MEDIAN
> 7.1.34 MIDRANGE
> 7.1.35 MIN
> 7.1.36 MOD
> 7.1.37 NATIONAL-OF
> 7.1.38 NUMVAL
> 7.1.39 NUMVAL-C
> 7.1.40 ORD
> 7.1.41 ORD-MAX
> 7.1.42 ORD-MIN
> 7.1.43 PRESENT-VALUE
> 7.1.44 RANDOM
> 7.1.45 RANGE
> 7.1.46 REM
> 7.1.47 REVERSE
> 7.1.48 SIN
> 7.1.49 SQRT
> 7.1.50 STANDARD-DEVIATION
> 7.1.51 SUM
> 7.1.52 TAN
> 7.1.53 UNDATE
> 7.1.54 UPPER-CASE
> 7.1.55 VARIANCE
> 7.1.56 WHEN-COMPILED
> 7.1.57 YEAR-TO-YYYY
> 7.1.58 YEARWINDOW
>
> 


0
wmklein (2605)
9/19/2006 1:51:22 AM
William M. Klein wrote in message ...
> wmklein <at> ix.netcom.com
>"robin" <robin_v@bigpond.com> wrote in message
>news:8GqPg.30657$rP1.17975@news-server.bigpond.net.au...

>>>> 6.    A DATE data type, and automatic handling of 2 and 4-digit years
>>>>        with century windowing; [COBOL too]
>>> For IBM mainframes, this has been available since within 12 months of when
>>> PL/I got it.
>>
>> I did mention that COBOL had it too.
> So why is it listed in "1-13"
>>
>>> (4/2 year date handling is also portable now that it is included in the
>>>ANSI/ISO Standard - but admittedly DATE data-types are not.)
>>
>> Then how are mixed 2-digit years and 4-digit years handled automatically?
> Thru "Millentium Language Extensions"

>So they are not part of COBOL?

>Perhaps you would explain how a date can be automatically
>recognized and converted from 2-digit year to 4-digit form
>and vice versa when there's no DATE type?

>In PL/I, the construct
>IF D1 > D2 THEN ...

>is recognized as a comparison between a 2-digit year and a 4-digit year
>(assume that D1 contains a 2-digit year, and D2 contains a 4-digit year),
>and the 2-digit year form is automatically converted to 4-digit year form
>for the comparison.

So it's DATE FORMAT in IBM COBOL.


0
robin_v (2737)
9/19/2006 4:06:40 PM
glen herrmannsfeldt wrote:

> Peter Flass <Peter_Flass@yahoo.com> wrote:
> (snip)
>  
> 
>>It seems better.  For one of the early releases I installed, I recall I 
>>had to set the "condition limit" to zero, or whatever, to get condition 
>>handling to work properly.  IOW, some error, possibly a hardware 
>>overflow or underflow, that was getting trapped to LE, which then 
>>checked the PL/I condition settings to determine what to do with it. 
> 
> 
> I thought that was the whole idea for SPM. (set program mask)
> Also, why PL/I has the exceptions that it does have, because
> those are the ones supported by S/360 hardware.  (Though SIZE
> isn't all that well supported, and is known to be slow.)
> 

That was my thought.  Despite what others have posted, I believe LE was 
originally written to support C, and then PL/I was backed into it.  As I 
said, my opinion is that it's gotten better in later releases.

0
Peter_Flass (956)
9/19/2006 10:02:07 PM
robin wrote:

> William M. Klein wrote in message ...
> 
>>wmklein <at> ix.netcom.com
>>"robin" <robin_v@bigpond.com> wrote in message
>>news:8GqPg.30657$rP1.17975@news-server.bigpond.net.au...
>>
>>>William M. Klein wrote in message ...
>>>
>>>>I was (sort-of with you until your last statement, but let's look at 1-13 for
>>>>today's IBM mainframe COBOL environment (which is all I was asking about)
>>>>
>>>>--
>>>>Bill Klein
>>>>wmklein <at> ix.netcom.com
>>>>"robin" <robin_v@bigpond.com> wrote in message
>>>>news:8dnOg.29059$rP1.14238@news-server.bigpond.net.au...
>>>>
>>>>>William M. Klein wrote in message ...
>>>>>
>>>>>>"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
>>>>>>news:v6kNg.243$W02.66@newsfe08.lga...
>>>>>>
>>>>>>>adaworks@sbcglobal.net wrote:
> 
> 
>>>>>2.    Error control, and consequent ease of recovery;
>>>>
>>>>On an IBM mainframe, full LE condition handling is available (along with
>>>>traditional COBOL declaratives)
>>>
>>>I'm not referring to LE handling.
>>>I'm referring to what's available in PL/I.
>>
>>How do you run PL/I "error handling" without USING LE for the run-time?
>>CALL is part of COBOL so it LE condition handling is part of IBM mainframe
>>COBOL.
> 
> 
> PL/I doesn't need LE to run.
> I do not use LE run-time.
> 
> 

What compiler/OS are you using.  I believe LE is required as of 
Enterprise PL/I, and was optional with 1.1.

0
Peter_Flass (956)
9/19/2006 10:04:29 PM
William M. Klein wrote:

> "robin" <robin_v@bigpond.com> wrote in message 
> news:OtHPg.31093$rP1.30566@news-server.bigpond.net.au...
> 
>>William M. Klein wrote in message ...
>>
>>>wmklein <at> ix.netcom.com
>>>"robin" <robin_v@bigpond.com> wrote in message
>>>news:8GqPg.30657$rP1.17975@news-server.bigpond.net.au...
> 
> <snip>
> 
>>>>Naturally, as it's not in COBOL, but nevertheless, it's still needed.
>>>
>>>Then why do the majoirty of IBM mainframe shops not need it?
>>
>>If the language doesn't have the facility, then - obviously - programmers
>>can't use it.
>>The facility was put in PL/I because it was important for commercial
>>programmers.
>>
> 
> 
> And your evidence for this being true is what?  Certainly, the need is their for 
> SCIENTIFIC data processing and that is a need that PL/I was originally designed 
> for.
> 

No.  PL/I was designed to do Commercial, Scientific, Systems 
Programming, Real-time, etc. with equal facility.

I used to do bit manipulation in COBOL before they added features to 
support it, but it certainly wasn't pretty.  CICS, among other places, 
used to treat bit fields as a fullword 'S9(9)' COMP. (FIXED BIN(31) in 
PL/I terms), and set/clear bits by adding or subtracting constant powers 
of two.

0
Peter_Flass (956)
9/19/2006 10:10:34 PM
William M. Klein wrote in message ...
>"robin" <robin_v@bigpond.com> wrote in message
>news:LtHPg.31089$rP1.12790@news-server.bigpond.net.au...
>> William M. Klein wrote in message ...
>>> wmklein <at> ix.netcom.com
><snip>
>>>How do you run PL/I "error handling" without USING LE for the run-time?
>>> CALL is part of COBOL so it LE condition handling is part of IBM mainframe
>>>COBOL.
>>
>> PL/I doesn't need LE to run.
>> I do not use LE run-time.

>On an IBM mainframe?

No.


0
robin_v (2737)
9/20/2006 12:34:01 AM
William M. Klein wrote in message ...
>Certainly "bit fields" can be used in business data processing.  I just haven't
>experienced any applications that REQUIRED them - at least not currently.  Any
>application that relies on a "punch card format" is NOT what I would
>(personally) consider a "current data processing" application.

The illustration was not about punch cards, but about
the need for BIT string processing, which has existed
from the early days of commercial computing.

>--
>Bill Klein
> wmklein <at> ix.netcom.com
>"robin" <robin_v@bigpond.com> wrote in message
>news:NtHPg.31092$rP1.7354@news-server.bigpond.net.au...
>> William M. Klein wrote in message ...
>>> wmklein <at> ix.netcom.com
>>>"robin" <robin_v@bigpond.com> wrote in message
>>>news:8GqPg.30657$rP1.17975@news-server.bigpond.net.au...
>>>> William M. Klein wrote in message ...
>>
>>>>>> 5.    Comprehensive functions for decimal arithmetic;
>>>>>Ain't nothing in PL/I that hasn't been in COBOL since day 1 (before the
>>>>>beginning of PL/I)
>>>>
>>>> Except COMPLEX, conversions between BIT and DECIMAL,
>>>> and probably more.
>>>  What does "COMPLEX" and "BIT" have to with DECIMAL?  (I agree that PL/I has
>>>support for BIT and COMPLEX not available in COBOL.  See my original note.  -
>>
>> In PL/I, decimal values can be COMPLEX.
>>
>> I thought I made it clear in my statement [quoted below] about surveys
>> that BIT variables can be used for holding yes/no answers.
>>
>> BIT values in PL/I may be converted to decimal,
>> and vice versa
>>
>>> Just a few weeks ago, while researching a first generation computer,
>>> I found that the input data was punched on cards, 12 answers per column,
>>> in 32 columns (giving 384 values per 80-column card).
>>> The data was held in storage as bit strings.


0
robin_v (2737)
9/20/2006 12:34:02 AM
William M. Klein wrote in message ...
>"robin" <robin_v@bigpond.com> wrote in message
>news:PtHPg.31094$rP1.8422@news-server.bigpond.net.au...
>> William M. Klein wrote in message ...
><snip>
>>>> Your response doesn't change the fact that PL/I is more suitable.
>>>  Based on what FACT?  (otrher than your opinion)  Certainly NOT based on
>>>"independent" mangagement decisions at the MAJORITY of IBM mainframe shops.
>>
>> We all know about "management decisions".
>> They are protecting their own empires and are intent in
>> consolidating their position in the firm.
>>
>> In any case, COBOL isn't restricted to IBM shops.

>Absolutely true.  Neither COBOL nor PL/I is limited to IBM shops.  The fact that
>COBOL is MUCH more common in IBM "OS/400" than PL/I (but not as common as RPG)
>doesn't say a lot about whether or not PL/I has or doesn't have advantages over
>COBOL for IBM mainframe business application design and implementation (the only
>thing that I was addressing originally).  In fact, the fact that there are at
>least two commercial .NET COBOL products (for Microsoft .NET environments) and
>ZERO PL/I commercial compilers (that I am aware of) for that same environment,
>also doesn't address my original point.
>
>HOWEVER, the fact that management at IBM mainframe "business" sites have NOT
>found a need to move from COBOL to PL/I

How do you explain that some mainframe sites did
in fact switch to PL/I, and some used both?


0
robin_v (2737)
9/20/2006 3:53:36 AM
William M. Klein wrote in message ...
>"robin" <robin_v@bigpond.com> wrote in message
>news:OtHPg.31093$rP1.30566@news-server.bigpond.net.au...
>> William M. Klein wrote in message ...
>>> wmklein <at> ix.netcom.com
>>>"robin" <robin_v@bigpond.com> wrote in message
>>>news:8GqPg.30657$rP1.17975@news-server.bigpond.net.au...
><snip>
>>>> Naturally, as it's not in COBOL, but nevertheless, it's still needed.
>>>Then why do the majoirty of IBM mainframe shops not need it?
>>
>> If the language doesn't have the facility, then - obviously - programmers
>> can't use it.
>> The facility was put in PL/I because it was important for commercial
>> programmers.
>
>And your evidence for this being true is what?

SHARE and GUIDE reps were on the design team.

>  Certainly, the need is their for
>SCIENTIFIC data processing and that is a need that PL/I was originally designed
>for.

PL/I was originally designed for:
1.    scientific uses
2.    commercial uses
3.    system programming uses
4.    list processing uses
5.    multi-programming
6.    real-time programming
7.    bullet-proof programs
and for mixtures of these.

    Users in the commercial field needed
features like those in Algol and Fortran, and scientific users
needed better I/O facilities than were in Fortran, and
especially dynamic data structures, so on.

This is why you find commercial features in PL/I.


>Can you point to any IBM mainframe shop or application that found that they HAD
>to use PL/I because COBOL couldn't do this for "commercial data processing"?

Quite a number took up PL/I, because COBOL
did not meet their requirements.



0
robin_v (2737)
9/20/2006 3:53:40 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:4X2Qg.32461$rP1.9364@news-server.bigpond.net.au...
> William M. Klein wrote in message ...
>>"robin" <robin_v@bigpond.com> wrote in message
>>news:PtHPg.31094$rP1.8422@news-server.bigpond.net.au...
>>> William M. Klein wrote in message ...
>><snip>
>>>>> Your response doesn't change the fact that PL/I is more suitable.
>>>>  Based on what FACT?  (otrher than your opinion)  Certainly NOT based on
>>>>"independent" mangagement decisions at the MAJORITY of IBM mainframe shops.
>>>
>>> We all know about "management decisions".
>>> They are protecting their own empires and are intent in
>>> consolidating their position in the firm.
>>>
>>> In any case, COBOL isn't restricted to IBM shops.
>
>>Absolutely true.  Neither COBOL nor PL/I is limited to IBM shops.  The fact 
>>that
>>COBOL is MUCH more common in IBM "OS/400" than PL/I (but not as common as RPG)
>>doesn't say a lot about whether or not PL/I has or doesn't have advantages 
>>over
>>COBOL for IBM mainframe business application design and implementation (the 
>>only
>>thing that I was addressing originally).  In fact, the fact that there are at
>>least two commercial .NET COBOL products (for Microsoft .NET environments) and
>>ZERO PL/I commercial compilers (that I am aware of) for that same environment,
>>also doesn't address my original point.
>>
>>HOWEVER, the fact that management at IBM mainframe "business" sites have NOT
>>found a need to move from COBOL to PL/I
>
> How do you explain that some mainframe sites did
> in fact switch to PL/I, and some used both?
>
>

That's easy to explain (and matches my original contention), you really CAN do 
most (not all) commercial data processing in IBM mainframe shops "equally well" 
in either COBOL or PL/I.  Which a shop uses (and "should use') is usually much 
more dependent upon the resources available at their shop and in their 
industry/location than it is upon the "power" of the language.

-- 
Bill Klein
 wmklein <at> ix.netcom.com 


0
wmklein (2605)
9/20/2006 8:18:38 PM
William M. Klein wrote:
> I still don't know what you think came in in 1971.  Are you saying a "run-time 
> library"?  COBOL certainly supported "RES and NORES" about that time (but 
> possibly later).  If you are saying the "base code" for what is currently 
> provided in the LE run-time library, then there ARE parts of it that still have 
> "IBM" prefixes that are PL/I specific - just as there are parts that have IGY 
> prefixes and are COBOL-specific.
> 
> Again, what exactly are you saying was "introduced in 1971" first for PL/I (then 
> for C then for other languages).
> 
> If you are talking about "ILC" (inter-language communication), the major 
> motivation for introducing LE was that ILC was AWFUL as defined in PL/I, COBOL, 
> and C before the LE-specific product (then part of the operating system) were 
> introduced.  Yes, it existed, but each language did it differently and I don't 
> know of ANY programmer who was happy with how it was done.

I'm saying that the whole thing is a child of the second-generation PL/I 
library of 1971, to which later compilers were eventually fitted.

-- 
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
   -- Charles Williams.  "Taliessin through Logres: Prelude"
0
jwkenne (1442)
9/21/2006 3:23:00 AM
William M. Klein wrote in message ...
>"robin" <robin_v@bigpond.com> wrote in message
>news:4X2Qg.32461$rP1.9364@news-server.bigpond.net.au...
>> William M. Klein wrote in message ...
>>>"robin" <robin_v@bigpond.com> wrote in message
>>>news:PtHPg.31094$rP1.8422@news-server.bigpond.net.au...
>>>> William M. Klein wrote in message ...
>>><snip>
>>>>>> Your response doesn't change the fact that PL/I is more suitable.
>>>>>  Based on what FACT?  (otrher than your opinion)  Certainly NOT based on
>>>>>"independent" mangagement decisions at the MAJORITY of IBM mainframe shops.
>>>>
>>>> We all know about "management decisions".
>>>> They are protecting their own empires and are intent in
>>>> consolidating their position in the firm.
>>>>
>>>> In any case, COBOL isn't restricted to IBM shops.
>>
>>>Absolutely true.  Neither COBOL nor PL/I is limited to IBM shops.  The fact that
>>>COBOL is MUCH more common in IBM "OS/400" than PL/I (but not as common as RPG)
>>>doesn't say a lot about whether or not PL/I has or doesn't have advantages over
>>>COBOL for IBM mainframe business application design and implementation (the
>>>only thing that I was addressing originally).  In fact, the fact that there are at
>>>least two commercial .NET COBOL products (for Microsoft .NET environments) and
>>>ZERO PL/I commercial compilers (that I am aware of) for that same environment,
>>>also doesn't address my original point.
>>>
>>>HOWEVER, the fact that management at IBM mainframe "business" sites have NOT
>>>found a need to move from COBOL to PL/I
>>
>> How do you explain that some mainframe sites did
>> in fact switch to PL/I, and some used both?
>
>That's easy to explain (and matches my original contention), you really CAN do
>most (not all) commercial data processing in IBM mainframe shops "equally well"
>in either COBOL or PL/I.

You're mixing the past and the present.
In the 60s, there were major differences between COBOL and PL/I.
Management was (still is) often reluctant to make changes,
or refused(s) to see the advantages of making a change.
In those days, processing could not be done <<"equally well"
in either COBOL or PL/I>>.

While some of those advantages have changed,
the fact remains that that there are significant differences still.
(one that you mention is of having to come in at 3am to fix a COBOL
program).

    There were some "studies" done about the languages,
but which turned out to be flawed because the authors of those
studies had blundered in their use of PL/I.

>  Which a shop uses (and "should use') is usually much
>more dependent upon the resources available at their shop and in their
>industry/location than it is upon the "power" of the language.

It's more often based on ignorance than anything else.


0
robin_v (2737)
9/26/2006 2:36:06 PM
"robin" <robin_v@bigpond.com> wrote in message 
news:qVaSg.36801$rP1.11799@news-server.bigpond.net.au...
> William M. Klein wrote in message ...
>>"robin" <robin_v@bigpond.com> wrote in message
>>news:4X2Qg.32461$rP1.9364@news-server.bigpond.net.au...
>>> William M. Klein wrote in message ...
>>>>"robin" <robin_v@bigpond.com> wrote in message
>>>>news:PtHPg.31094$rP1.8422@news-server.bigpond.net.au...
>>>>> William M. Klein wrote in message ...
>>>><snip>
>>>>>>> Your response doesn't change the fact that PL/I is more suitable.
>>>>>>  Based on what FACT?  (otrher than your opinion)  Certainly NOT based on
>>>>>>"independent" mangagement decisions at the MAJORITY of IBM mainframe 
>>>>>>shops.
>>>>>
>>>>> We all know about "management decisions".
>>>>> They are protecting their own empires and are intent in
>>>>> consolidating their position in the firm.
>>>>>
>>>>> In any case, COBOL isn't restricted to IBM shops.
>>>
>>>>Absolutely true.  Neither COBOL nor PL/I is limited to IBM shops.  The fact 
>>>>that
>>>>COBOL is MUCH more common in IBM "OS/400" than PL/I (but not as common as 
>>>>RPG)
>>>>doesn't say a lot about whether or not PL/I has or doesn't have advantages 
>>>>over
>>>>COBOL for IBM mainframe business application design and implementation (the
>>>>only thing that I was addressing originally).  In fact, the fact that there 
>>>>are at
>>>>least two commercial .NET COBOL products (for Microsoft .NET environments) 
>>>>and
>>>>ZERO PL/I commercial compilers (that I am aware of) for that same 
>>>>environment,
>>>>also doesn't address my original point.
>>>>
>>>>HOWEVER, the fact that management at IBM mainframe "business" sites have NOT
>>>>found a need to move from COBOL to PL/I
>>>
>>> How do you explain that some mainframe sites did
>>> in fact switch to PL/I, and some used both?
>>
>>That's easy to explain (and matches my original contention), you really CAN do
>>most (not all) commercial data processing in IBM mainframe shops "equally 
>>well"
>>in either COBOL or PL/I.
>
> You're mixing the past and the present.
> In the 60s, there were major differences between COBOL and PL/I.
> Management was (still is) often reluctant to make changes,
> or refused(s) to see the advantages of making a change.
> In those days, processing could not be done <<"equally well"
> in either COBOL or PL/I>>.
>
> While some of those advantages have changed,
> the fact remains that that there are significant differences still.
> (one that you mention is of having to come in at 3am to fix a COBOL
> program).
>
>    There were some "studies" done about the languages,
> but which turned out to be flawed because the authors of those
> studies had blundered in their use of PL/I.
>
>>  Which a shop uses (and "should use') is usually much
>>more dependent upon the resources available at their shop and in their
>>industry/location than it is upon the "power" of the language.
>
> It's more often based on ignorance than anything else.
>
>

Either that, or it is based on managers that are as "didactic" as you are (but 
more often on the OTHER side) and don't actually look for the best tool for each 
job.

I think your credibility in this newsgroup is probably OK, but it sure would be 
helped by your understanding (and reflecting in your posts) the difference 
between opinion and fact.

The reality is that in the world of business data processing BOTH COBOL and PL/I 
are "loosing ground".  However, it is also true that PL/I is looser more than 
COBOL - at least partially because PL/I never had as wide a base of actual 
production code.  Whether this was an "error in judgement" in those selecting 
business application programming tool or not, it IS a fact while most 
(definitely NOT all) of your "advantages" are opinion, not fact.  (And you still 
refuse to acknowledge the facts of where another language IS a better choice - 
for whatever reason - than PL/I).

Unlike D.F.  I try not to dwell on this, but it is worth mentioning every once 
in a while.  I see this newsgroup as a great place to discuss how to solve 
application problems using PL/I.  It is even a good place to see both good and 
better ways to do things in PL/I.  I fully accept that if you want to find out 
about OTHER languages, this is not (nor should it be) the best place and that 
finding "unbiased" opinions is probably not something that anyone should expect 
here.

-- 
Bill Klein
 wmklein <at> ix.netcom.com 


0
wmklein (2605)
9/26/2006 10:35:45 PM
William M. Klein wrote in message <4XhSg.18593$Db2.16610@fe09.news.easynews.com>...
>
>Either that, [or] don't actually look for the best tool for each job.

If one looks for the "best tool for each job",
the job will never get done.


0
robin_v (2737)
9/27/2006 2:35:10 PM
"Tom Linden" <tom@kednos-remove.com> wrote in message
news:op.tf1q6laatte90l@hyrrokkin...
> On Sun, 17 Sep 2006 09:21:35 -0700, robin <robin_v@bigpond.com> wrote:
>
> > You can use the typed pointers whenever you want.
>
> Typed pointers is an oxymoron, it is attributed pointers.

Typed pointers, which is their correct name,
are called 'handles' in PL/I.  They are not amorphous.

> Pointers are a bona fide data type in PL/I unlike other languages,
> but you knew that.

So are handles.


0
robin_v (2737)
10/4/2006 12:22:40 AM
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message news:4XhSg.18593
>
> The reality is that in the world of business data processing BOTH COBOL and 
> PL/I are "losing ground".
I have a friend who makes a good living traveling
to COBOL user sites to help them upgrade their
programmers to object-oriented COBOL.   OOCOBOL
seems to be the right choice for current COBOL shops
that want to take advantage of the object model in
their own software.

In fact, I find it silly for those shops to switch to C++ or
Java when it is so much easier for their personnel to
learn OOCOBOL and get greater productivity sooner.

Richard Riehle 


0
adaworks2 (748)
10/9/2006 5:29:05 PM
As a COBOL "bigot" - I also find it "silly" when people try to "migrate" from 
one (supported) programming language (COBOL) to another.  However, I do see it 
happening relatively often.  (Sometimes, it is even successful <G>)

-- 
Bill Klein
 wmklein <at> ix.netcom.com
<adaworks@sbcglobal.net> wrote in message 
news:BFvWg.21137$Ij.5756@newssvr14.news.prodigy.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message 
> news:4XhSg.18593
>>
>> The reality is that in the world of business data processing BOTH COBOL and 
>> PL/I are "losing ground".
> I have a friend who makes a good living traveling
> to COBOL user sites to help them upgrade their
> programmers to object-oriented COBOL.   OOCOBOL
> seems to be the right choice for current COBOL shops
> that want to take advantage of the object model in
> their own software.
>
> In fact, I find it silly for those shops to switch to C++ or
> Java when it is so much easier for their personnel to
> learn OOCOBOL and get greater productivity sooner.
>
> Richard Riehle
> 


0
wmklein (2605)
10/9/2006 8:18:50 PM
Reply:

Similar Artilces:

To OOP or not to OOP
This is partially an opinion question. I have some modularization for my main site using vanilla PHP. I'm a one-man operation. Is there any major benefit to learning and using OOP? I have lots of other stuff to be spending my limited intelligence learning. On May 28, 3:44 pm, "Gregor" <rmba...@comcast.net> wrote: > This is partially an opinion question. I have some modularization for my > main site using vanilla PHP. I'm a one-man operation. > > Is there any major benefit to learning and using OOP? I have lots of other > stuff to be spending ...

Why xml:lang instead of lang?
What was the reason to introduce a new attribute "xml:lang" instead of "lang"? This bothers both authors and browsers in different language versions: HTML 4, XHTML 1.0, XHTML 1.1. HTML has only "lang"; XHTML 1.1 has only "xml:lang"; XHTML 1.0 has both! For example, Mozilla 1.7 recognizes the lang attribute http://www.unics.uni-hannover.de/nhtcapri/temp/lang-attribute.htm but it does not recognize the xml:lang attribute. http://www.unics.uni-hannover.de/nhtcapri/temp/lang-attribute.xhtml What do we gain from "xml:lang"? Andreas Prilop wrote: > What was the reason to introduce a new attribute "xml:lang" > instead of "lang"? > What do we gain from "xml:lang"? By putting the attribute in the general and predefined namespace http://www.w3.org/XML/1998/namespace it can be used by any XML application (e.g. XHTML, SVG) without any further effort and without any danger of colliding with attributes in no namespace a particular XML application might want to define. -- Martin Honnen http://JavaScript.FAQTs.com/ Andreas Prilop wrote: > What was the reason to introduce a new attribute "xml:lang" > instead of "lang"? Since it is useful to have a means of describing language in the core of XML. It only looks silly from an (X)HTML-centric viewpoint. -- David Dorward http://dorward.me.uk/ In article <Pine.GSO.4.44.0603311415390.8640-100000@s5b004.rrzn.u...

Re: PL/I EXCEPTIONS (was: PL/I)
From: Peter Flass <Peter_Flass@Yahoo.com>, Road Runner Date: Sat, 22 Jan 2005 01:18:55 GMT .. | Well, it never occurred to me either, until I wrote it. I'm not sure | it would work, although it seems valid. Actually, now that I've written | it I've thought of some uses, for example: | IF print_debug_info THEN DO; | ON ERROR PUT DATA; | END; | at the beginning of a program, so the user can control, maybe by a | run-time option, how errors are to be handled. .. You mean :- .. IF print_debug_info THEN DO; ON ERROR BEGIN; ON ERROR SYSTEM; PUT DATA; END; END; Yeah, that. robin wrote: > From: Peter Flass <Peter_Flass@Yahoo.com>, Road Runner > Date: Sat, 22 Jan 2005 01:18:55 GMT > . > | Well, it never occurred to me either, until I wrote it. I'm not sure > | it would work, although it seems valid. Actually, now that I've written > | it I've thought of some uses, for example: > | IF print_debug_info THEN DO; > | ON ERROR PUT DATA; > | END; > | at the beginning of a program, so the user can control, maybe by a > | run-time option, how errors are to be handled. > . > You mean :- > . > IF print_debug_info THEN DO; > ON ERROR BEGIN; ON ERROR SYSTEM; PUT DATA; END; > END; ...

Re: PL/I ON statement (was: PL/I)
From: "Mark Yudkin" <myudkinATcompuserveDOTcom@boing.org>, CompuServe Interactive Services Date: Wed, 26 Jan 2005 07:55:48 +0100 .. | Important correction inline. .. I know that. I was referring to the case when the current procedure has been called by another. I was not clear. .. More than one ON statement can be executed in a given procedure (for the same condition), in which case the new ON-unit merely supplants the previous one. .. | "robin" <robin_v@bigpond.mapson.com> wrote in message news:OUYId.131519$K7.53859@news-server.bigpond.net.au... | > Subject: Re: PL/I ON Statement (was: PL/I) | > From: "Tom Linden" <tom@kednos.com>, Kednos | > Date: Sat, 22 Jan 2005 16:25:07 -0800 | > | On Sat, 22 Jan 2005 19:35:18 GMT, Peter Flass <Peter_Flass@Yahoo.com> wrote: | > | > Right, but only if the statement was executed, that is, the bit | > | > 'print_debug_info' had been set before executing this construct (again, | > | > so I think, I'll have to test it.) The idea is to easily control the | > | > action for ERROR, in this case the generation of debug output, at run | > | > time. | > | | > | I think a test is in order. | > | When the compiler encounters the ON stmnt | > | it knows nothing of the the IF statement, | > | > ON is an executable statement. | > It is perfectly at home in an IF statement. Or a DO loop. Or wherever. | > In this case, it i...

OOP
Of these languages, I'd like opinions as to wether or not they're true OOP languages and the best most powerful and easiest to use. Smalltalk Java Perl Objective-C C++ Thanks. -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 100,000 Newsgroups - 19 Different Servers! =----- On Tue, 24 Feb 2004 08:48:54 -0500, Bill Cunningham wrote: > Of these languages, I'd like opinions as to wether or not they're true OOP > languages and the best most powerful and easiest to use. > ...

lang
fortran ...

OOP
Hi from a newbe. I have read some articles over Java and that took my interest. I have bought a number of books and works out the samples. My ages is 73 and I have experience with macros etc in spread sheets and have done some work in Clipper in the good old DOS days. (Train your brains) In Java I have a (small?) problem. In an Applet I have two buttons. When I push button 1 the background color of the button changes. No problem. When I after that push button 2, button 1 must go back to the original background color. I try to save the original background color on the following way; <button1.getBackground()> this gives a color object. From this color object I will save the colors Red, Green and Blue so these can be used to set back the old background color, on the next way; <int x = (button1.getBackground()).getRed()> for Red, but this don't works. I get a null pointer exception (InvocationTargetExption) and I don't understand this. I have used a debugger, looked a number of books but it doesn't help me. Maybe there are better solutions and I have interest in these, but for me is important to understand why I not get the <int x>. Thanks for help Arie Tamboer a.tamboer@home.nl A.Tamboer wrote: > Hi from a newbe. ... > In Java I have a (small?) problem. In an Applet .. Applets (or GUI'd applications) are not the best things for Java newbe to start with. <http://www.physci.org/codes/javafaq.jsp#appfirst> &...

OOP
Hi. I'm familiar with OOP, and I use it in VB, but I don't have that talent in PERL. For example, I write a good bit of code, using syntax like: if($FORM{'calculate_shipping'} eq "") { &show_calc_shipping; } else { $ship_data = &calc_shipping; } That's easy, but I don't understand the following: $rateReqEl->setAttribute('USERID', 'xxxxxxxx'); $rateReqEl->setAttribute('PASSWORD', 'xxxxxxxx'); $rateReqDoc->appendChild($rateReqEl); $ Even my CGI book doesn't talk like that. Where...

A Lange & Sohne Lange 1 Watches: Quality A Lange & Sohne Discount Watches
A Lange & Sohne Lange 1 Watches: Quality A Lange & Sohne Discount Watches Quality A Lange & Sohne Lange 1 Watches http://a-lange-sohne-watches.pxhelp.com/a-lange-sohne-lange-1.html Thank you for choosing http://www.pxhelp.com/ Discount A Lange & Sohne Watches http://a-lange-sohne-watches.pxhelp.com/ We guarantee our A Lange & Sohne Lange 1 Watches and A Lange & Sohne Lange 1 Luxury Watches aren't just a simple imitation. We use the same fine materials and technology that the original does. Each A Lange & Sohne Lange 1 Watch produced is examined carefully by ...

A Lange & Sohne Grand Lange 1 Watches: Quality A Lange & Sohne Discount Watches
A Lange & Sohne Grand Lange 1 Watches: Quality A Lange & Sohne Discount Watches Quality A Lange & Sohne Grand Lange 1 Watches http://a-lange-sohne-watches.pxhelp.com/a-lange-sohne-grand-lange-1.html Thank you for choosing http://www.pxhelp.com/ Discount A Lange & Sohne Watches http://a-lange-sohne-watches.pxhelp.com/ We guarantee our A Lange & Sohne Grand Lange 1 Watches and A Lange & Sohne Grand Lange 1 Luxury Watches aren't just a simple imitation. We use the same fine materials and technology that the original does. Each A Lange & Sohne Grand Lange 1 Watc...

OOPS OOPS- How Do I Work With CS2 HISTORY?
I want to start a new thread and am not doing too good am I? Back on my friend's CS2 on his PC again - WXP PRO SP2. I am now looking at CS2's 'history' window. From what I read in the Help, the things I do are tracked in that window. I created a new little window to play with, and drew four separate small 'brush' strokes. I see that each time I did a stroke, a line was entered in the history window. Then I thought I should be able to step back and forth through my strokes by either clicking on a line in the history window or by selecting edit>step backward (o...

OOPS! I did it Again!
I downloaded another book! 1-4390-7810-6 Financial Management: Theory and Practice (Book Only) 13th edition I gave it to an entire class of undergrads, at least 20. Let's do the math! New: $175 * 20 = $3,500 Used: $135 * 20 = $2,700 So I saved each student between #135 and $175 each. How does that make you feel? Would this qualify as grand theft? On 11/15/2012 2:23 PM, Justin wrote: > I downloaded another book! > 1-4390-7810-6 > Financial Management: Theory and Practice (Book Only) 13th edition > I gave it to an entire class of undergrads, at least 20. > Let's do the math! > > New: $175 * 20 = $3,500 > > Used: $135 * 20 = $2,700 > > So I saved each student between #135 and $175 each. > > How does that make you feel? > Would this qualify as grand theft? A puss like you will blab about it here anonymously, but would NEVER mouth off to the legal dept of the publisher. On Thu, 15 Nov 2012 15:04:56 -0500, DFS <nospam@dfs.com> wrote: >On 11/15/2012 2:23 PM, Justin wrote: >> I downloaded another book! >> 1-4390-7810-6 >> Financial Management: Theory and Practice (Book Only) 13th edition >> I gave it to an entire class of undergrads, at least 20. >> Let's do the math! >> >> New: $175 * 20 = $3,500 >> >> Used: $135 * 20 = $2,700 >> >> So I saved each student between #135 and $175 each. >> &g...

[PL/SQL] DataBASE Interaction with PL/SQL
Hello Oracle Guru's, I know that PL/SQL does't accept any user inputs. but i need the following functionality like And Please do not ask the reason for. (My question is coming at the end of this part) Algorithm 1.Execute a procedure 2. accept some input parameters 3. check for some condition 4. pass those accepted parameter to the Dynamic SQL/cursor etc.... 5. Print the output using DBMS.Package 6.The END Here is a sample procedure, but this procedure will accept parameters only when a run the entire procedure (first time) ------------------------------------------- create or replace procedure test as t_empno varchar2(10) := '&empno'; t_ename varchar2(100); begin Select empname into t_ename from empmaster Where empno=t_empno; dbms_output.put_line('Name: '|| t_ename); -- p(t_ename) ; --thanks for asktom.oracle.com end; ---------------------------------------------- Out/put (Image only some i/o is translated from japaneseto english) empno....?: E1234567 old 3: v_empno varchar2(10) := '&empno'; new 3: v_empno varchar2(10) := 'E1234567'; Procedure created SQL> exec test nameofthe employ here PL/SQLcompleted succ.... ------------------------------------------------- My question is How can i write a PL/SQL to perform the above algorithm i.e When i say EXEC test the following screnn should appear empno....?: E1234567 old 3: v_empno varchar2(10) := '&...

OOps!
I am the Dragon Slayer ...

PL/I (aka PL/1) ISO Standard
I can't tell if those asking about the PL/1 (should be PL/I?) Standard in the preprocessor thread were talking about the macro preprocessor or the language itself. However, if anyone is actually interested in the ISO Standard for the language, please check out the web site at: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=12907 to the best of my memory (and I could be totally wrong on this) at least the "mainframe" compiler from IBM *never* actually conformed to this Standard. (There were some pretty obscure but real incompatibles between what the ISO Standard required and what IBM users expected). I do recall that there were several "conforming" compilers on other platforms (notably Unix and I think either Unisys or HP). Unlike Fortran and COBOL, the ISO PL/I (PL/1) standardization process is now "moribund". I think you can submit interpretation request and defect reports, but there is no ongoing work to ever produce another edition of the Standard. "Bill Klein" <wmklein@noreply.ix.netcom.com> wrote in message news:KpuVn.496096$rq1.248525@en-nntp-02.dc1.easynews.com... |I can't tell if those asking about the PL/1 (should be PL/I?) Standard It's "PL/I". | in the preprocessor thread were talking about the macro preprocessor or the | language itself. It was clear that it was the preprocessor. | However, if anyone is actually interested in the ISO | Standa...

oops
Question 1:- Describe the following with the help of examples: 1)Generalization and its role in Inheritance. 2)abstract Classes 3)State Diagrams. 4)OMT and its impact in programming. 5)future of Object Oriented languages. Qusetion2: -Identify the Objects in Railway Reservation System,and make Object diagram for it. Question3:- develop an object oriented Analysis and design Document for an Advertising agency.The System should display the type of products advertised,coverage area etc: the design document should contain: i)Complete class information. ii) object Diagram. iii)Inheritance Diagram. i am student please provide quality material , i shall be thankfull to all those, will help me or those will try to help me. plz reply before 30 march2005 thankyou rohit srivastava india [rx@india.com] Since you are a student, it is to your benefit to understand rather than to repeat what other have said. So, let us turn this around and provide a mutual benefit. Answer these questions to the best of your abilities, and ask for corrections. Our benefit is keeping the discussion manageable. Your benefits are self-respect, correction to your knowledge - and you do not have to share your mark. FGB ...

PL/I
PL/I users might like to view: http://www.users.bigpond.com/robin_v/plistuff.htm ...

pl/i
Hi, I am not a cobol programmer (although i know it a little), but for the current project we need a cobol program that will call a pl/i program. Anyone knows how? What things i have to consider? Louis You don't tell us your environment (operating system or compiler) - but if this HAPPENS to be an IBM mainframe environment (where PL/I is medium common), check out: "11.0 Chapter 11. Communicating between COBOL and PL/I" at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA4110/11.0 -- Bill Klein wmklein <at> ix.netcom.com "Louis De Bevere&quo...

Oops
I meant: Tag: g1 g2 g3 g4 e1 e2 e3 e4 ...

oops
Question 1:- Describe the following with the help of examples: 1)Generalization and its role in Inheritance. 2)abstract Classes 3)State Diagrams. 4)OMT and its impact in programming. 5)future of Object Oriented languages. Qusetion2: -Identify the Objects in Railway Reservation System,and make Object diagram for it. Question3:- develop an object oriented Analysis and design Document for an Advertising agency.The System should display the type of products advertised,coverage area etc: the design document should contain: i)Complete class information. ii) ob...

Oops!
Turns out the iPod Touch does have iOS. If my post shows up about Pixo OS and Apple fanbois (I tried to cancel it), I was wrong. LOLLERCOASTER "Clavicus Vile" <clavicus.vile@oblivion.org> wrote in message news:ilqnd7$tpl$1@news.albasani.net... ooops! - is that what the homeless bum said when he couldn't "pull out" of your mother fast enough and she got knocked up with a retard like you? > > LOLLERCOASTER > we're not laughing with you moron. we're laughing at you. Clavicus Vile stated in post ilqnd7$tpl$1@news.albasani.net on 3/16/11 9:10 AM: > Turns out the iPod Touch does have iOS. > > If my post shows up about Pixo OS and Apple fanbois (I tried to cancel it), > I was wrong. > > LOLLERCOASTER > > I have an iPod Touch and could have verified this for you. :) -- [INSERT .SIG HERE] "Snit" <usenet@gallopinginsanity.com> wrote in message news:C9A63164.921B1%usenet@gallopinginsanity.com... > Clavicus Vile stated in post ilqnd7$tpl$1@news.albasani.net on 3/16/11 > 9:10 > AM: > >> Turns out the iPod Touch does have iOS. >> >> If my post shows up about Pixo OS and Apple fanbois (I tried to cancel >> it), >> I was wrong. >> >> LOLLERCOASTER >> >> > I have an iPod Touch and could have verified this for you. :) LOLLERCOASTER I'm going to believe something that's Snit verified? Good jok...

Against OOP
The new SOA (service oriented architecture) is a vast repudiation of Object Oriented Programming. It casts doubts on such chestnuts as c++, java and c#. The basis of SOA are distributed methods. These methods can exists external to all calling programs. They are, in effect, widely distributed /friend/ functions. The idea of 'inheretance' is a huge presumption, not born out by fact. The typical situation is that classes are not re-used...they are written for very specific things, just like procedural code. So why bother? Encapsulation is never used. Data is always stor...

Oops!
Here's a rather interesting picture. I hadn't thought they could actually do this. http://www.hawkfeather.com/wa-aero/grafx/trident-oops.jpg Michael x-- 100 Proof News - http://www.100ProofNews.com x-- 3,500+ Binary NewsGroups, and over 90,000 other groups x-- Access to over 1 Terabyte per Day - $8.95/Month x-- UNLIMITED DOWNLOAD Michael Emrys wrote: > Here's a rather interesting picture. I hadn't thought they could actually do > this. > > http://www.hawkfeather.com/wa-aero/grafx/trident-oops.jpg > > Michael > > ...

Oops
Well don't I feel foolish. Basically, the problem that comes up with the block of code from my last (abbreviated) message is that at a certain point in the execution of the program, it throws an exception that the wxClientDC is invalid. Any idea as to what causes this? __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --------------------------------------------------------------------- To unsubscribe, e-mail: wx-users-unsubscribe@lists.wxwidgets.org For additional commands, e-...

Web resources about - PL/I and OOP - comp.lang.pl1

WATCH LIVE: Protesters Block Arizona Highway Close to Trump Rally
Protesters near Phoenix have blocked a major highway leading to where Donald Trump will be holding a rally later this afternoon. Hordes of protesters ...

Flydubai flight FZ981 crash — RT News
A Flydubai Boeing-737-800 has crashed during landing in the southern Russian city of Rostov-on-Don. All the passengers and crew on board have ...

Gawker lost its sex-tape fight with Hulk Hogan — but it's not the first time the site has been caught ...
Media company Gawker recently lost a lawsuit brought against it over a leaked sex tape it posted in 2012 featuring former professional wrestler ...

2 Houston Robbery Suspects Arraigned After Police Shooting
Two robbery suspects arrested after a deadly police-involved shooting in Houston have been arraigned

Suicide bomb attack in Istanbul kills 5, including Israeli
Fox News Suicide bomb attack in Istanbul kills 5, including Israeli Fox News ISTANBUL – A suicide attack on Istanbul's main pedestrian shopping ...

NCAA Tournament Ratings Jump For CBS Over First Friday Of 2015, ‘Dateline’ Up
A 70-63 win over the Michigan Wolverines just day after St. Patrick's is a very nice start to this year's NCAA Tournament for the Notre Dame ...

This week’s top stories: Apple’s Mar. 21 event, new iPhone SE & 9.7-inch iPad Pro details, iOS 9.3 beta ...
With Apple’s iPhone SE press event scheduled for this upcoming Monday, March 21st, it’s no surprise that our reports surrounding what to expect ...

Full Episode: GMA 03/19/16: Adam LaRoche's MLB Retirement Situation Highlights
Paris Terror Attack Suspect Arrest Details Start to Emerge; Hulk Hogan Secures Victory in Gawker Sex Tape Case

Body of Missing Teen Adriana Coronado Found in Texas
On Friday, the search for 14-year-old Adriana Coronado was called off when a body discovered by a gardener last Wednesday was confirmed as being ...

Microsoft apologizes for GDC party with scantily clad dancers
(By Anya George Tharakan, Reuters) – Microsoft apologized for hiring dancers dressed as skimpily-clad schoolgirls for its Game Developer Conference ...

Resources last updated: 3/19/2016 6:38:54 PM