f



Paper on PL/I

I have to write a paper on PL/I for my programming languages course and
one of the things I need to cover is interesting language features such
as the treatment of gotos and labels, and ON conditions.  I haven't
been able to find much information online about these topics and was
wondering if anyone could suggest some resources I could use.  Thanks
so much in advance.

~kim

0
vogt7987 (4)
11/25/2005 5:35:03 PM
comp.lang.pl1 1741 articles. 0 followers. Post Follow

250 Replies
1944 Views

Similar Articles

[PageSpeed] 2

On 25 Nov 2005 09:35:03 -0800, FSNole <vogt@cs.fsu.edu> wrote:

> I have to write a paper on PL/I for my programming languages course and
> one of the things I need to cover is interesting language features such
> as the treatment of gotos and labels, and ON conditions.  I haven't
> been able to find much information online about these topics and was
> wondering if anyone could suggest some resources I could use.  Thanks
> so much in advance.
>
> ~kim
>
We have some links on our site to resources that you might find useful
www.kednos.com  PL/I's block structure with lexical scoping and  
ON-conditions
would make an interesting topic, and might lead people to the realization
the C and C++ are pedestrian at best.

Tom
0
tom284 (1839)
11/25/2005 6:11:11 PM
There's a fairly good bibliography at 
http://home.nycap.rr.com/pflass/plibib.htm
Lots of the articles, especially the ACM stuff, should be available online.

FSNole wrote:
> I have to write a paper on PL/I for my programming languages course and
> one of the things I need to cover is interesting language features such
> as the treatment of gotos and labels, and ON conditions.  I haven't
> been able to find much information online about these topics and was
> wondering if anyone could suggest some resources I could use.  Thanks
> so much in advance.
> 
> ~kim
> 

0
Peter_Flass (956)
11/25/2005 9:09:02 PM
FSNole wrote:

> I have to write a paper on PL/I for my programming languages course and
> one of the things I need to cover is interesting language features such
> as the treatment of gotos and labels, and ON conditions.  I haven't
> been able to find much information online about these topics and was
> wondering if anyone could suggest some resources I could use.  Thanks
> so much in advance.

To give you a hint, PL/I allows GOTO using LABEL variables between 
procedures.  Somewhat similar to C's setjmp/longjmp, one can pass a 
LABEL variable to another routine.

Another interesting language feature is the range of data conversions
PL/I allows.  Conversions between character and numeric types are done 
when needed, consider:

DCL  (X,Y) CHAR(20);
X='1234';
Y=SQRT(X);
PUT LIST(X,Y);

-- glen

0
gah (12851)
11/25/2005 9:11:11 PM
FSNole wrote:

>if anyone could suggest some resources I could use.
try IBM manual pages:
http://www-306.ibm.com/software/awdtools/pli/plizos/library/

<shamelessplug>
if you need to expirement with just the syntax of pl1, try to visit
pl1gcc.sourceforge.net
</shamelessplug>
> 
> ~kim
Henrik
0
11/25/2005 9:55:45 PM
FSNole wrote in message <1132940103.169696.12330@z14g2000cwz.googlegroups.com>...
>I have to write a paper on PL/I for my programming languages course and
>one of the things I need to cover is interesting language features such
>as the treatment of gotos and labels, and ON conditions.  I haven't
>been able to find much information online about these topics and was
>wondering if anyone could suggest some resources I could use.  Thanks
>so much in advance.


http://en.wikibooks.org/wiki/Software_Engineers_Handbook:Language_Dictionary:PLI

http://www.users.bigpond.com/robin_v/pli-n8.htm
and follow links to earlier newsletters

http://www.users.bigpond.com/robin_v/resource.htm

http://www.users.bigpond.com/robin_v/pli_faq.htm

>~kim


0
robin_v (2737)
11/25/2005 11:09:21 PM
There was a paper written in the 80's (I think) titile something like
Return of PL/I King of programming languages, anybody have a reference to  
it

On Fri, 25 Nov 2005 23:09:21 GMT, robin <robin_v@bigpond.com> wrote:

> FSNole wrote in message  
> <1132940103.169696.12330@z14g2000cwz.googlegroups.com>...
>> I have to write a paper on PL/I for my programming languages course and
>> one of the things I need to cover is interesting language features such
>> as the treatment of gotos and labels, and ON conditions.  I haven't
>> been able to find much information online about these topics and was
>> wondering if anyone could suggest some resources I could use.  Thanks
>> so much in advance.
>
>
> http://en.wikibooks.org/wiki/Software_Engineers_Handbook:Language_Dictionary:PLI
>
> http://www.users.bigpond.com/robin_v/pli-n8.htm
> and follow links to earlier newsletters
>
> http://www.users.bigpond.com/robin_v/resource.htm
>
> http://www.users.bigpond.com/robin_v/pli_faq.htm
>
>> ~kim
>
>

0
tom284 (1839)
11/25/2005 11:50:15 PM
In summary of your programming languages paper you shud mention that PL/I is 
NOT a viable language
as below link indicates  (no usage/development whatsoever)

http://news.google.com/news?as_q=pl/i

vs  one of the most active development languages

http://news.google.com/news?as_q=fortran



0
dave_frank (2243)
11/26/2005 11:28:55 AM
Tom Linden wrote in message ...
>There was a paper written in the 80's (I think) titile something like
>Return of PL/I King of programming languages, anybody have
> a reference to  it
It was called "Has the King returned?".


0
robin_v (2737)
11/26/2005 2:35:08 PM
On Sat, 26 Nov 2005 14:35:08 GMT, robin <robin_v@bigpond.com> wrote:

> Tom Linden wrote in message ...
>> There was a paper written in the 80's (I think) titile something like
>> Return of PL/I King of programming languages, anybody have
>> a reference to  it
> It was called "Has the King returned?".
>
>
So, Robin,  do you have a link for it?
Tom

0
tom284 (1839)
11/26/2005 3:16:17 PM
"FSNole" <vogt@cs.fsu.edu> writes:
> I have to write a paper on PL/I for my programming languages course and
> one of the things I need to cover is interesting language features such
> as the treatment of gotos and labels, and ON conditions.  I haven't
> been able to find much information online about these topics and was
> wondering if anyone could suggest some resources I could use.  Thanks
> so much in advance.

Or perhaps you could make contact with some of the Multics PL/I
people and get their take on things.  They are probably all
retired by now and have the time to correspond with you.
Somebody posted a Multics alumni URL recently...
0
mojaveg595 (241)
11/26/2005 9:16:19 PM
David Frank wrote in message ...
>In summary of your programming languages paper you shud mention that PL/I is
>NOT a viable language
>as below link indicates  (no usage/development whatsoever)

Google gives only a small time-frame window into news.
In any case, you're lying again, because you know
that IBM regularly releases updates for its PL/I compilers.
Just yesterday was an announcement of an update
carried in this very newsgroup :

"We have new kit available, and updated the website with a
"link to numerous systems and applications programming
"examples.
"www.kednos.com
"Tom


0
robin_v (2737)
11/27/2005 12:33:11 AM
Thank you everyone for all of the info!  I'm definately going to
research all of the sites given.  I'm guessing that this is the paper
you are referring to Mr. Linden http://www.idinews.com/pl1return.pdf.
I will check this out as well.  It's not due for another week so if
anyone has any more good links or tips feel free to post of course!

Thanks Again,
~kim :)

0
vogt7987 (4)
11/27/2005 5:10:59 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:b97if.4861$ea6.3844@news-server.bigpond.net.au...
> David Frank wrote in message ...
>>In summary of your programming languages paper you shud mention that PL/I 
>>is
>>NOT a viable language
>>as below (restored) link indicates  (no usage/development whatsoever)
>

http://news.google.com/news?as_q=pl/i

vs  one of the most active development languages

http://news.google.com/news?as_q=fortran



> Google gives only a small time-frame window into news.
> In any case, you're lying again, because you know
> that IBM regularly releases updates for its PL/I compilers.
> Just yesterday was an announcement of an update
> carried in this very newsgroup :
>
> "We have new kit available, and updated the website with a
> "link to numerous systems and applications programming
> "examples.
> "www.kednos.com
> "Tom
>
>

Me-thinks only IBM and  the kednos compiler
(for some unknown reason, since its platform is not being manufactured 
anymore)
are experiencing any current vendor interest in updates.

But I said USER development interest,  for which there hasnt been any since 
I first spotted and posted the PL/I DE-LIAR link above several months ago..





0
dave_frank (2243)
11/27/2005 10:56:48 AM
On 26 Nov 2005 21:10:59 -0800, FSNole <vogt@cs.fsu.edu> wrote:

> Thank you everyone for all of the info!  I'm definately going to
> research all of the sites given.  I'm guessing that this is the paper
> you are referring to Mr. Linden http://www.idinews.com/pl1return.pdf.
> I will check this out as well.  It's not due for another week so if
> anyone has any more good links or tips feel free to post of course!
>
> Thanks Again,
> ~kim :)
>

Thank you for the reference.  You might like to post an outline for
comments.

Tom

0
tom284 (1839)
11/27/2005 4:50:43 PM
On Sun, 27 Nov 2005 10:56:48 GMT, David Frank <dave_frank@hotmail.com>  
wrote:

>
> "robin" <robin_v@bigpond.com> wrote in message
> news:b97if.4861$ea6.3844@news-server.bigpond.net.au...
>> David Frank wrote in message ...
>>> In summary of your programming languages paper you shud mention that  
>>> PL/I
>>> is
>>> NOT a viable language
>>> as below (restored) link indicates  (no usage/development whatsoever)
>>
>
> http://news.google.com/news?as_q=pl/i
>
> vs  one of the most active development languages
>
> http://news.google.com/news?as_q=fortran
>
>
>
>> Google gives only a small time-frame window into news.
>> In any case, you're lying again, because you know
>> that IBM regularly releases updates for its PL/I compilers.
>> Just yesterday was an announcement of an update
>> carried in this very newsgroup :
>>
>> "We have new kit available, and updated the website with a
>> "link to numerous systems and applications programming
>> "examples.
>> "www.kednos.com
>> "Tom
>>
>>
>
> Me-thinks only IBM and  the kednos compiler
> (for some unknown reason, since its platform is not being manufactured
> anymore)
> are experiencing any current vendor interest in updates.

Sales of OpenVMS platforms were about $4Billion last fiscal year.  It,  
together
with PL/I is used by most of the major car manufacturers, Power, Steel,  
Space,
Defense, Health Care and other fields.
>
> But I said USER development interest,  for which there hasnt been any  
> since
> I first spotted and posted the PL/I DE-LIAR link above several months  
> ago..
>
>
>
>
>

0
tom284 (1839)
11/27/2005 4:55:37 PM
you should check the job listings on monster.  I look for both fortran 
and PL/1.  PL/1 has active use in Great Britain and various places in 
the US.mostly banking and insurance.  Most of the Fortran listings tend 
to be legacy support or conversion of fortran legacy software to 
C/C++/Java.  I see more PL/1 developemtn jobs then I see fortran jobs.



David Frank wrote:
> "robin" <robin_v@bigpond.com> wrote in message 
> news:b97if.4861$ea6.3844@news-server.bigpond.net.au...
> 
>>David Frank wrote in message ...
>>
>>>In summary of your programming languages paper you shud mention that PL/I 
>>>is
>>>NOT a viable language
>>>as below (restored) link indicates  (no usage/development whatsoever)
>>
> 
> http://news.google.com/news?as_q=pl/i
> 
> vs  one of the most active development languages
> 
> http://news.google.com/news?as_q=fortran
> 
> 
> 
> 
>>Google gives only a small time-frame window into news.
>>In any case, you're lying again, because you know
>>that IBM regularly releases updates for its PL/I compilers.
>>Just yesterday was an announcement of an update
>>carried in this very newsgroup :
>>
>>"We have new kit available, and updated the website with a
>>"link to numerous systems and applications programming
>>"examples.
>>"www.kednos.com
>>"Tom
>>
>>
> 
> 
> Me-thinks only IBM and  the kednos compiler
> (for some unknown reason, since its platform is not being manufactured 
> anymore)
> are experiencing any current vendor interest in updates.
> 
> But I said USER development interest,  for which there hasnt been any since 
> I first spotted and posted the PL/I DE-LIAR link above several months ago..
> 
> 
> 
> 
> 
0
multicsfan (63)
11/27/2005 5:32:07 PM
The Multics website is http://www.multicians.org/

PL/1 was the systems programming language on Multics.  Pretty much all 
system osftware was written in PL/1 with assembler only used where required.

Everett M. Greene wrote:

> "FSNole" <vogt@cs.fsu.edu> writes:
> 
>>I have to write a paper on PL/I for my programming languages course and
>>one of the things I need to cover is interesting language features such
>>as the treatment of gotos and labels, and ON conditions.  I haven't
>>been able to find much information online about these topics and was
>>wondering if anyone could suggest some resources I could use.  Thanks
>>so much in advance.
> 
> 
> Or perhaps you could make contact with some of the Multics PL/I
> people and get their take on things.  They are probably all
> retired by now and have the time to correspond with you.
> Somebody posted a Multics alumni URL recently...
0
multicsfan (63)
11/27/2005 5:34:30 PM
On Sun, 27 Nov 2005 17:34:30 GMT, multicsfan <multicsfan@hotmail.com>  
wrote:

> PL/1 was the systems programming language on Multics.  Pretty much all  
> system osftware was written in PL/1 with assembler only used where  
> required.
>
VOS went one step further and included capability for making Kernel calls.
I did the same about 20 years ago for a Unix implementation, and as an  
experiment
demonstated seemless replacement of assembly code in the Unix kernel.  To  
use it,
however, to replace rom code would require absolute addressing, which  
could be
done but was something I never bothered with.

Tom
0
tom284 (1839)
11/27/2005 8:07:11 PM
After researching some more.  I found this speech by Edsgar Dijkstra
who stated in 1974, "I absolutely fail to see how we can keep our
growing programs firmly within our intellectual grip when by its sheer
baroqueness the programming language -our basic tool, mind you!-
already escapes our intellectual control." in reference to PL/I
(http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html).
 Any comments?

0
vogt7987 (4)
11/27/2005 9:10:38 PM
Programs have to do what they have to do.  If they're written in a 
simpler programming language, like C or Pascal, all you're doing is 
replacing compiler code and libraries with user code and libraries to 
perform the same task.  One result is C's infamous "buffer overrun" 
problems because some programmer forgot to check string lengths and/or 
array bounds.  This is *possible* with PL/I, but is considerably more 
difficult to program.

See Karger's paper:
Karger, Paul A., and Roger R. Schell, Thirty Years Later:
Lessons from the Multics Security Evaluation, Proc ACSAC 2002.
IBM Research Report RC22534.
http://www.acsac.org/2002/papers/classic-multics.pdf

He attributes a great deal of the security of Multics to PL/I. I think 
thirty years of C shows he's right.

FSNole wrote:
> After researching some more.  I found this speech by Edsgar Dijkstra
> who stated in 1974, "I absolutely fail to see how we can keep our
> growing programs firmly within our intellectual grip when by its sheer
> baroqueness the programming language -our basic tool, mind you!-
> already escapes our intellectual control." in reference to PL/I
> (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html).
>  Any comments?
> 

0
Peter_Flass (956)
11/27/2005 9:42:21 PM
Thanks for the info and new link.  I know my professor is not fond of
the language (ADA is his baby) so I'm trying to back up my statements
as much as possible.

0
vogt7987 (4)
11/27/2005 10:38:51 PM
On Sun, 27 Nov 2005 21:42:21 GMT, Peter Flass <Peter_Flass@Yahoo.com>  
wrote:

> Programs have to do what they have to do.  If they're written in a  
> simpler programming language, like C or Pascal, all you're doing is  
> replacing compiler code and libraries with user code and libraries to  
> perform the same task.  One result is C's infamous "buffer overrun"  
> problems because some programmer forgot to check string lengths and/or  
> array bounds.  This is *possible* with PL/I, but is considerably more  
> difficult to program.
>
> See Karger's paper:
> Karger, Paul A., and Roger R. Schell, Thirty Years Later:
> Lessons from the Multics Security Evaluation, Proc ACSAC 2002.
> IBM Research Report RC22534.
> http://www.acsac.org/2002/papers/classic-multics.pdf
>
> He attributes a great deal of the security of Multics to PL/I. I think  
> thirty years of C shows he's right.
>
> FSNole wrote:
>> After researching some more.  I found this speech by Edsgar Dijkstra
>> who stated in 1974, "I absolutely fail to see how we can keep our
>> growing programs firmly within our intellectual grip when by its sheer
>> baroqueness the programming language -our basic tool, mind you!-
>> already escapes our intellectual control." in reference to PL/I
>> (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html).
>>  Any comments?
>>
>
I think what Dijkstra failed to realize is that you could form well  
contained
usage subsets from the full language which were well contained and defined.
Admittedly, it is a large language, but when you compare to C++ it is small
in the sense that with C++ class libraries can be thought of as part of the
locution and therefor its semantics as part of the language.  Freiburghouse
invented subset G for some of the reasons Dijkstra cites, leaving out  
things
he thought unnecessary such as CONTROLLED, GENERIC and a few others.

The 1976 ANSI PL/I I think is still the most elegant language  
specification written.
I am disappointed by the clutter that IBM has introduced in recent  
versions, which
are ad hoc in the sense that they are inconsistent with the PL/I defining  
mechanism,
for example, char varyingz as oppose to char options(c).
0
tom284 (1839)
11/28/2005 12:34:13 AM
David Frank wrote in message ...
>
>"robin" <robin_v@bigpond.com> wrote in message
>news:b97if.4861$ea6.3844@news-server.bigpond.net.au...
>> David Frank wrote in message ...
>> Google gives only a small time-frame window into news.
>> In any case, you're lying again, because you know
>> that IBM regularly releases updates for its PL/I compilers.
>> Just yesterday was an announcement of an update
>> carried in this very newsgroup :
>>
>> "We have new kit available, and updated the website with a
>> "link to numerous systems and applications programming
>> "examples.
>> "www.kednos.com
>> "Tom
>
>Me-thinks only IBM and  the kednos compiler
>(for some unknown reason, since its platform is not being manufactured
>anymore)
>are experiencing any current vendor interest in updates.
>
>But I said USER development interest, for which there hasnt been any since

Google isn't a measure of user interest.

That IBM and other suppliers are updating their compilers
indicates user interest and development interest.

In any case, that YOU didn't find any was because you
don't know how to use Google, as stated before.


0
robin_v (2737)
11/28/2005 3:19:19 AM
FSNole wrote in message <1133125838.129416.290400@g47g2000cwa.googlegroups.com>...
>After researching some more.  I found this speech by Edsgar Dijkstra
>who stated in 1974, "I absolutely fail to see how we can keep our
>growing programs firmly within our intellectual grip when by its sheer
>baroqueness the programming language -our basic tool, mind you!-
>already escapes our intellectual control." in reference to PL/I
>(http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html).
> Any comments?

He didn't know what he was talking about.
[His comments could well apply to C, however.]

He was promoting Pascal - a langage that
lacked exponentiation and string handling ;
the design of input was defective.
At the time, the reasoning that it was more fun
to do exponentiation other ways.
    Come to think of it, you couldn't write algorithms
-- in the general sense of the word --
using arrays, because Pascal lacked dynamic arrays.
This was on account of the "strong typing" that
was heavily promoted at the time.
    Ada suffered from the same deficiency until it
was recognized that you really do need to have dynamic
arrays (unconstrained).





0
robin_v (2737)
11/28/2005 5:12:14 AM
FSNole wrote in message <1133125838.129416.290400@g47g2000cwa.googlegroups.com>...
>After researching some more.  I found this speech by Edsgar Dijkstra
>who stated in 1974, "I absolutely fail to see how we can keep our
>growing programs firmly within our intellectual grip when by its sheer
>baroqueness the programming language -our basic tool, mind you!-
>already escapes our intellectual control." in reference to PL/I

http://www.users.bigpond.com/robin_v/why_not.htm

could be of interest.




0
robin_v (2737)
11/28/2005 5:12:15 AM
FSNole wrote in message <1133125838.129416.290400@g47g2000cwa.googlegroups.com>...
>After researching some more.  I found this speech by Edsgar Dijkstra
>who stated in 1974, "I absolutely fail to see how we can keep our
>growing programs firmly within our intellectual grip when by its sheer
>baroqueness the programming language -our basic tool, mind you!-
>already escapes our intellectual control." in reference to PL/I
> Any comments?

The fallacy in this argument -

When a language lacks the facilties required,
it may be necessary to write some of the code in
assembler, or in another high-level language.

Learning another language typically doubles the
amount of knowledge of HLLs needed to write a program
to solve a given problem.

As well, the different languages mean different syntax etc
must be mastered.

The fallacy of using a small language such as Pascal
is that that is sufficient.  In practice it is not.  The question is,
does one learn two languages having different syntaxes,
or one larger language (e.g. PL/I) that will do admirably for the
job.

The richness of PL/I is such that it is rarely necessary to
resort to using assembler to accomplish the needed operations.
Or other languages.

PL/I can be used for both commercial programming tasks
as well as technical (scientific).


0
robin_v (2737)
11/28/2005 5:12:16 AM
Peter Flass wrote in message <1Lpif.48397$uC3.28951@twister.nyroc.rr.com>...
>Programs have to do what they have to do.  If they're written in a
>simpler programming language, like C or Pascal, all you're doing is
>replacing compiler code and libraries with user code and libraries to
>perform the same task.

In general, yes.  In particular, it isn't so definite.
The C code is less clear, and is less robust.
The equivalent Pascal or C code is more verbose
because it lacks the facilities.  Errors slip through
more easily.

>  One result is C's infamous "buffer overrun"
>problems because some programmer forgot to check string lengths

There's more to it than that.  It's not that they forget.  They just don't
bother.
One fundamental problem with C is the library "approach".
Many functions return values [error indications] that typically
are ignored.
This situation is brought about by the lack of distinction between subroutines
and functions.

> and/or
>array bounds.  This is *possible* with PL/I, but is considerably more
>difficult to program.

Indeed.  The PL/I language provides the means to automatically check
substring and subscript references.
Likewise, overflow, etc, are (others can be) automatically checked -
something that other langauges don't.
Just last week I took a published C program, and translated it
to another language.
The first thing that it did was to crash -- on account of an integer
overflow -- without producing any results.
[no, it wasn't on account of a coding error of mine.  Upon suppression of
the integer overflow, the program produced the published results.]
    The fact that one of the overflowed result became
negative, and propagated itself through 100,000 values,
went unnoticed by  the originators of the algorithm and
paper in question.
    The algorithm was intended by the authors to be portable,
but on a machine having a different wordsize, the algorithm
would produce completely different results.

>See Karger's paper:
>Karger, Paul A., and Roger R. Schell, Thirty Years Later:
>Lessons from the Multics Security Evaluation, Proc ACSAC 2002.
>IBM Research Report RC22534.
>http://www.acsac.org/2002/papers/classic-multics.pdf
>
>He attributes a great deal of the security of Multics to PL/I. I think
>thirty years of C shows he's right.




0
robin_v (2737)
11/28/2005 5:12:16 AM
FSNole wrote:
> Thanks for the info and new link.  I know my professor is not fond of
> the language (ADA is his baby) so I'm trying to back up my statements
> as much as possible.
> 
Good luck.  As you have probably already discovered, programming 
language preferences -- especially among academics -- are the cause of 
many religious wars.  For example, observe the reactions of disciples of 
St. Nik to any criticism of Pascal.

Sometime after Dijkstra's previously cited comments, there was a paper 
entitled something like "Teaching the Fatal Disease" listing all sort of 
supposed problems with PL/I -- most of which boiled down to complaints 
that PL/I had too many features but users kept asking for more.  Pascal 
was held up as the counterexample of an ideal programming language, 
having so few features it would be easy to learn and remember.  The only 
problem with that comparison was that everyone I knew at that time who 
used Pascal extensively complained Pascal didn't have enough features 
and kept asking for more -- even those who disparaged PL/I for having 
"too many" features.  When I pointed this out to one of St. Nik's 
disciples, he became extremely upset (but he also stopped complaining 
about PL/I -- at least in my presence).

You'll find similar support for Ada, Fortran, Cobol, C, C++, etc.

I'd avoid any comparative value judgments in your paper if your 
professor really likes Ada (or any language other than PL/I).


Bob Lidral
lidral  at  alum  dot  mit  dot  edu
0
11/28/2005 9:28:34 AM
"Tom Linden" <tom@kednos.com> wrote in message 
news:ops0wryzgszgicya@hyrrokkin...
>
> Sales of OpenVMS platforms were about $4Billion last fiscal year.  It, 
> together
> with PL/I is used by most of the major car manufacturers, Power, Steel, 
> Space,
> Defense, Health Care and other fields.

Intel bought the rights to the alpha chip from HP along with the 
DEC->Compaq->HP alpha/Fortran developer staff.
 just to shut down their production and competition to their own 
x86/Fortran..

Show us a current link to buy a US produced  NEW ALPHA platform computer..



0
dave_frank (2243)
11/28/2005 9:51:22 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:XGuif.5479$ea6.826@news-server.bigpond.net.au...
> David Frank wrote in message ...
>>
>
>>But I said USER development interest, for which there hasnt been any since
>
> Google isn't a measure of user interest.
>
> That IBM and other suppliers are updating their compilers
> indicates user interest and development interest.
>
> In any case, that YOU didn't find any was because you
> don't know how to use Google, as stated before.
>

As stated before, if you disagree then show us how to get Google news to 
show user interest instead of just the same old, same old  horse-hockey from 
you. 


0
dave_frank (2243)
11/28/2005 9:53:30 AM
On Mon, 28 Nov 2005 09:51:22 GMT, David Frank <dave_frank@hotmail.com>  
wrote:

>
> "Tom Linden" <tom@kednos.com> wrote in message
> news:ops0wryzgszgicya@hyrrokkin...
>>
>> Sales of OpenVMS platforms were about $4Billion last fiscal year.  It,
>> together
>> with PL/I is used by most of the major car manufacturers, Power, Steel,
>> Space,
>> Defense, Health Care and other fields.
>
> Intel bought the rights to the alpha chip from HP along with the
> DEC->Compaq->HP alpha/Fortran developer staff.
>  just to shut down their production and competition to their own
> x86/Fortran..
>
> Show us a current link to buy a US produced  NEW ALPHA platform  
> computer..
>
>
>
www.hp.com

0
tom284 (1839)
11/28/2005 1:34:38 PM
On Mon, 28 Nov 2005 05:12:15 GMT, robin <robin_v@bigpond.com> wrote:

>
> http://www.users.bigpond.com/robin_v/why_not.htm
> could be of interest.

I don't see Kednos listed at the bottom of the page:-(
0
tom284 (1839)
11/28/2005 1:38:37 PM
"Tom Linden" <tom@kednos.com> wrote in message 
news:ops0ydb0cvzgicya@hyrrokkin...
> On Mon, 28 Nov 2005 09:51:22 GMT, David Frank <dave_frank@hotmail.com> 
> wrote:
>
>>
>> "Tom Linden" <tom@kednos.com> wrote in message
>> news:ops0wryzgszgicya@hyrrokkin...
>>>
>>> Sales of OpenVMS platforms were about $4Billion last fiscal year.  It,
>>> together
>>> with PL/I is used by most of the major car manufacturers, Power, Steel,
>>> Space,
>>> Defense, Health Care and other fields.
>>
>> Intel bought the rights to the alpha chip from HP along with the
>> DEC->Compaq->HP alpha/Fortran developer staff.
>>  just to shut down their production and competition to their own
>> x86/Fortran..
>>
>> Show us a current link to buy a US produced  NEW ALPHA platform 
>> computer..
>>
>>
>>
> www.hp.com


http://www.theinquirer.net/?article=17954

indicates HP has given up on the alpha chip,
plus since there are no more VAX's being built,   Kednos PL/I has NO 
FUTURE...
 


0
dave_frank (2243)
11/28/2005 9:45:51 PM
David Frank wrote in message ...
>
>"robin" <robin_v@bigpond.com> wrote in message
>news:XGuif.5479$ea6.826@news-server.bigpond.net.au...
>> David Frank wrote in message ...
>>>
>>>But I said USER development interest, for which there hasnt been any since
>>
>> Google isn't a measure of user interest.
>>
>> That IBM and other suppliers are updating their compilers
>> indicates user interest and development interest.
>>
>> In any case, that YOU didn't find any was because you
>> don't know how to use Google, as stated before.
>
>As stated before, if you disagree then show us how to get Google news to
>show user interest instead of just the same old, same old  horse-hockey from
>you.

Others have already done this, but you chose to ignore
them.



0
robin_v (2737)
11/28/2005 11:30:26 PM
Bob Lidral wrote:
> FSNole wrote:
> 
>> Thanks for the info and new link.  I know my professor is not fond of
>> the language (ADA is his baby) so I'm trying to back up my statements
>> as much as possible.
>>
> Good luck.  As you have probably already discovered, programming 
> language preferences -- especially among academics -- are the cause of 
> many religious wars.  For example, observe the reactions of disciples of 
> St. Nik to any criticism of Pascal.

A *good* professor, however, will grade on the work the student has done 
whether or not he/she agrees with the argument, as long as it is supported.

> 
> Sometime after Dijkstra's previously cited comments, there was a paper 
> entitled something like "Teaching the Fatal Disease" listing all sort of 
> supposed problems with PL/I -- most of which boiled down to complaints 
> that PL/I had too many features but users kept asking for more.

The ACM website has this online.  The author also has a copy at:
http://plg.uwaterloo.ca/~holt/papers/fatal_disease.html

0
Peter_Flass (956)
11/28/2005 11:53:51 PM
On Mon, 28 Nov 2005 23:53:51 GMT, Peter Flass <Peter_Flass@Yahoo.com>  
wrote:

> Bob Lidral wrote:
>> FSNole wrote:
>>
>>> Thanks for the info and new link.  I know my professor is not fond of
>>> the language (ADA is his baby) so I'm trying to back up my statements
>>> as much as possible.
>>>
>> Good luck.  As you have probably already discovered, programming  
>> language preferences -- especially among academics -- are the cause of  
>> many religious wars.  For example, observe the reactions of disciples  
>> of St. Nik to any criticism of Pascal.
>
> A *good* professor, however, will grade on the work the student has done  
> whether or not he/she agrees with the argument, as long as it is  
> supported.
>
>>  Sometime after Dijkstra's previously cited comments, there was a paper  
>> entitled something like "Teaching the Fatal Disease" listing all sort  
>> of supposed problems with PL/I -- most of which boiled down to  
>> complaints that PL/I had too many features but users kept asking for  
>> more.
>
> The ACM website has this online.  The author also has a copy at:
> http://plg.uwaterloo.ca/~holt/papers/fatal_disease.html
>
Thank you for that link.  BTW, it is wise to moderate one's assertions,
we had full ansi PL/I running on a minicomputer in the late 70's, and
Freiburghouse bootstrapped a pretty full subset (What would become G)
onto a Nova ca. 1975

Tom
0
tom284 (1839)
11/29/2005 12:10:28 AM
Peter Flass wrote:

> A *good* professor, however, will grade on the work the student has done 
> whether or not he/she agrees with the argument, as long as it is supported.
> 
You're absolutely correct.  However I spent too many years in or near 
academia and discovered there that many people, even some good 
professors, have difficulty seeing the validity of any argument that 
reaches a conclusion with which they disagree.  This is, of course, not 
limited to academia, just less appropriate there than in most other 
venues.  That said, the paper is yours, the professor is yours, and the 
grade is yours, so the decision is yours.  I would still counsel against 
comparative value judgments of the form "language X {is better, has 
better features than, etc.} language Y" or even the milder "feature A of 
language X is better than feature B of language Y" in any paper for 
which you are paid or receive a grade about which you care.

And I echo Tom Linden's thanks for the link to that paper.


Bob Lidral
lidral  at  alum  dot  mit  dot  edu
0
11/29/2005 3:59:48 AM
Excellent ideas for the paper and some fine discussions about this or that 
feature of PL/I (as long as one ForTran fanatic is ignored).  What I'd like 
to see however implemented as soon as possible is an expansion of the 
excellent input/output features for paper and cards/prompts/etc. that helped 
cement PL/I's reputation such that it could handle Windows/Linux/whatever 
screen I/O such that C and its derivatives could be *completely dispensed 
with*.  [Mark Yudkin's routines, however well-worked on and supported, are 
not the answer as they still require one knowing C and that junk!!!]  I wish 
to program in PL/I _without_ having to deal with another language just 
because of the latter's being used with a specific O/S!  Can't one develop a 
compiler that would allow generic I/O with menus and all the goodies of 
Windows (or other interactive screen handling) - surely it ought to be 
possible! 



0
azdamyan (6)
11/29/2005 4:27:49 AM
David Frank wrote:

(snip)

> indicates HP has given up on the alpha chip,
> plus since there are no more VAX's being built,   Kednos PL/I has NO 
> FUTURE...

Quick, name the THREE processor that run VMS.

One is made by intel.

-- glen

0
gah (12851)
11/29/2005 6:29:50 AM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:sIOdnaAtefjDaBbenZ2dnUVZ_tydnZ2d@comcast.com...
> David Frank wrote:
>
> (snip)
>
>> indicates HP has given up on the alpha chip,
>> plus since there are no more VAX's being built,   Kednos PL/I has NO 
>> FUTURE...
>
> Quick, name the THREE processor that run VMS.
>
> One is made by intel.
>
> -- glen
>

www.kednos.com

1st paragraph Tom sez his PL/I runs on Alpha and Vax..    he sez nada about 
Intel 


0
dave_frank (2243)
11/29/2005 1:16:14 PM
FSNole wrote in message <1133125838.129416.290400@g47g2000cwa.googlegroups.com>...
>After researching some more.  I found this speech by Edsgar Dijkstra

(http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html).
> Any comments?

This paper does not say anything much of substance, and of what little there
is, is wrong.  He states that the subroutine is important in the design of the
EDSAC (1949).  With great irony, in the ACM *Turing* Lecture, he omits any
reference to Turing and his design of the ACE in 1946, which included
a hardware stack for subroutine calling and returning.  As well,
Turing and his team developed software (subroutines) for a variety of tasks
in 1947-1949 for that machine - subroutines that were used
on the Pilot ACE.

An exception to the 'substance' remark above :-
        "program testing can be a very effective
        "way to show the presence of bugs,
        "but is hopelessly inadequate for
        "showing their absence."

The remarks about hardware (3rd generation, mid 1960s)
appear to be addressed to the IBM System 360.
That machine was a step backwards when compared to the
stack machines of the Burroughs line and of the English Electric KDF9,
both of which were introduced in 1963.
The S/360 lacked a stack, and executing subroutines was
relatively expensive [real-time requirements were addressed
in the nearly-identical RCA Spectra series and the English Electric
System 4 series].

    The paper [address?] was largely a complaint about anything and
everything - complaints about Dutch authorities for not
recognizing his occupation, complaints about languages (Algol, FORTRAN,
PL/I), about programming, BNF, etc. [strangely, no complaints about
Pascal and COBOL], complaints about people, hardware interrupts,
and so on.












0
robin_v (2737)
11/29/2005 2:24:00 PM
FSNole wrote in message <1132940103.169696.12330@z14g2000cwz.googlegroups.com>...
>I have to write a paper on PL/I for my programming languages course and
>one of the things I need to cover is interesting language features such
>as the treatment of gotos and labels, and ON conditions.  I haven't
>been able to find much information online about these topics and was
>wondering if anyone could suggest some resources I could use.  Thanks
>so much in advance.

In the mid-1990s I wrote a paper on the new features of
PL/I for OS/2, that was published in the ACM Sigplan Notices.

>~kim


0
robin_v (2737)
11/29/2005 10:55:24 PM
On 26 Nov 2005 21:10:59 -0800, FSNole <vogt@cs.fsu.edu> wrote:

> Thank you everyone for all of the info!  I'm definately going to
> research all of the sites given.  I'm guessing that this is the paper
> you are referring to Mr. Linden http://www.idinews.com/pl1return.pdf.

As for PL/I for OS/2 of 1994 and subsequently, a function could return
an aggregate result (i.e. an array). [page 10]  The Enterprise
and VA PL/I compilers -derived from PL/I for OS/2- still do.
Whether that was correct or not in 1993 when the paper was written,
I don't know.

> I will check this out as well.  It's not due for another week so if
> anyone has any more good links or tips feel free to post of course!
>
> Thanks Again,
> ~kim :)





0
robin_v (2737)
11/29/2005 10:55:25 PM
Not really a compiler-type feature.  It's too complicated, and it varies 
too much from one system to another.  However, I'l like to see a library 
like OS/2 Rexx's "VREXX" package, that really makes it simple to write 
simple windowed applications.

Alexander Damyanovich wrote:
> Excellent ideas for the paper and some fine discussions about this or that 
> feature of PL/I (as long as one ForTran fanatic is ignored).  What I'd like 
> to see however implemented as soon as possible is an expansion of the 
> excellent input/output features for paper and cards/prompts/etc. that helped 
> cement PL/I's reputation such that it could handle Windows/Linux/whatever 
> screen I/O such that C and its derivatives could be *completely dispensed 
> with*.  [Mark Yudkin's routines, however well-worked on and supported, are 
> not the answer as they still require one knowing C and that junk!!!]  I wish 
> to program in PL/I _without_ having to deal with another language just 
> because of the latter's being used with a specific O/S!  Can't one develop a 
> compiler that would allow generic I/O with menus and all the goodies of 
> Windows (or other interactive screen handling) - surely it ought to be 
> possible! 
> 
> 
> 

0
Peter_Flass (956)
11/30/2005 12:24:39 AM
Alexander Damyanovich wrote:
> Excellent ideas for the paper and some fine discussions about this or that 
> feature of PL/I (as long as one ForTran fanatic is ignored).  What I'd like 
> to see however implemented as soon as possible is an expansion of the 
> excellent input/output features for paper and cards/prompts/etc. that helped 
> cement PL/I's reputation such that it could handle Windows/Linux/whatever 
> screen I/O such that C and its derivatives could be *completely dispensed 
> with*.  [Mark Yudkin's routines, however well-worked on and supported, are 
> not the answer as they still require one knowing C and that junk!!!]  I wish 
> to program in PL/I _without_ having to deal with another language just 
> because of the latter's being used with a specific O/S!  Can't one develop a 
> compiler that would allow generic I/O with menus and all the goodies of 
> Windows (or other interactive screen handling) - surely it ought to be 
> possible! 
> 
> 
> 
I don't have windows PL/I so I don't know for sure, but even in Personal PL/I 
for OS/2 which is relatively ancient, it is straightforward to invoke any of the 
operating system API calls.  All you have to do is write a package or two that 
talks to the API, which admittedly uses C-like calling conventions, and 
everything else you write talks to your packages in PL/I terms.  I can't believe 
that the windows versions don't have a similar facility.

For example, using packages I developed for file processing, keyboard handling, 
and screen display, I recently wrote a hex viewer/editor that can browse and 
make non size-changing edits in arbitrary files of any size, i.e, greater that 
2GB, without ever having more that a few kilobytes of the file resident in 
memory.  The size of the exe file is 25088.  Of course it does use PL/I DLL's 
whose total size is around 800K not to mention an even larger volume OS/2 dll's.

I can use this program to poke around in large wav, mpg, or vob files that make 
other hex viewers I have tried choke.
0
jjw (608)
11/30/2005 4:40:02 AM
You don't need to _know_ C in order to use the Winows PL/I, but because the 
MS documentation and most of the standard text books on the native API are 
written for C programmers, it helps if you can read C declarations.

None of this is compiler-related - the API is a call-level API. PL/I for 
Windows provides support for that API (some of this as a result of specific 
"requirements" I created).

The problems with generic GUI models are the enormity of the task (consider 
Java) and the look-and-feel mismatch of pure genericity (c.f. Java using 
non-Windows widgets). That said, I provide support for Tcl/Tk (and much of 
the X11 model) - perhaps the most frequently user of the standard widget 
toolbox. Using Tcl/Tk as a widget library does come closer to addressing 
your wish. What is probably needed now is an event handler model that allows 
you to write your events handlers in pure PL/I, rather than needing a Tcl 
wrapper. Perl/Tk, Python/TK, Rexx/Tk, ... all do this.

Sicne my approach was to use VB6 to code the GUI, with the business logic in 
PL/I, I never had the time or the need to address your requirement. Why 
don't you take on the project of coding a library to simplify use of Tk from 
within PL/I?

- Mark Yudkin

"Alexander Damyanovich" <azdamyan@inetsonic.com> wrote in message 
news:rMQif.850$N7.510@fe13.usenetserver.com...
> Excellent ideas for the paper and some fine discussions about this or that 
> feature of PL/I (as long as one ForTran fanatic is ignored).  What I'd 
> like to see however implemented as soon as possible is an expansion of the 
> excellent input/output features for paper and cards/prompts/etc. that 
> helped cement PL/I's reputation such that it could handle 
> Windows/Linux/whatever screen I/O such that C and its derivatives could be 
> *completely dispensed with*.  [Mark Yudkin's routines, however well-worked 
> on and supported, are not the answer as they still require one knowing C 
> and that junk!!!]  I wish to program in PL/I _without_ having to deal with 
> another language just because of the latter's being used with a specific 
> O/S!  Can't one develop a compiler that would allow generic I/O with menus 
> and all the goodies of Windows (or other interactive screen handling) - 
> surely it ought to be possible!
>
> 


0
11/30/2005 6:48:27 AM
David Frank wrote:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
> news:sIOdnaAtefjDaBbenZ2dnUVZ_tydnZ2d@comcast.com...

>>David Frank wrote:

>>(snip)

>>>indicates HP has given up on the alpha chip,
>>>plus since there are no more VAX's being built,   Kednos PL/I has NO 
>>>FUTURE...

>>Quick, name the THREE processor that run VMS.

>>One is made by intel.

> www.kednos.com

> 1st paragraph Tom sez his PL/I runs on Alpha and Vax..    he sez nada about 
> Intel 

Did my question say anything about PL/I?  I just asks about VMS!

By the way, the processor in question has a name that rhymes with a 
light metal, but is often given a nickname that rhymes with a famous 
ship and also a famous movie.

-- glen

0
gah (12851)
11/30/2005 8:19:50 AM
Peter Flass wrote in message ...
>Not really a compiler-type feature.  It's too complicated, and it varies
>too much from one system to another.  However, I'l like to see a library
>like OS/2 Rexx's "VREXX" package, that really makes it simple to write
>simple windowed applications.

PL/I for OS/2 has a PM interface (a la windows).


0
robin_v (2737)
11/30/2005 1:39:48 PM
You need SDL, shouldn't be too hard to port, written in PL/I.
This was written almost 25 years ago!
Tom

HERMES> help sdl

SDL


    The VAX Structure Definition Language (VAX  SDL)  is  used  to  write
    source  statements  that  describe  data  structures  and that can be
    translated to source statements in other languages.  You can  include
    the resulting output files in a corresponding target language program
    for subsequent compilation.

    Because  VAX  SDL  is  compiler-  and  language-independent,  it   is
    particularly useful for maintaining multilanguage implementations.

    Format:
            SDL[/qualifier[...]] file-spec[/qualifier[...]],...

    VAX SDL supports the following VMS languages:

    o VAX Ada       o VAX BASIC   o VAX BLISS   o VAX C          o VAX  
DATATRIEVE
    o VAX FORTRAN   o VAX MACRO   o VAX Pascal  o VAXELN Pascal  o VAX PL/I



On Wed, 30 Nov 2005 07:48:27 +0100, Mark Yudkin  
<myudkinATcompuserveDOTcom@boingboing.org> wrote:

> You don't need to _know_ C in order to use the Winows PL/I, but because  
> the
> MS documentation and most of the standard text books on the native API  
> are
> written for C programmers, it helps if you can read C declarations.
>
> None of this is compiler-related - the API is a call-level API. PL/I for
> Windows provides support for that API (some of this as a result of  
> specific
> "requirements" I created).
>
> The problems with generic GUI models are the enormity of the task  
> (consider
> Java) and the look-and-feel mismatch of pure genericity (c.f. Java using
> non-Windows widgets). That said, I provide support for Tcl/Tk (and much  
> of
> the X11 model) - perhaps the most frequently user of the standard widget
> toolbox. Using Tcl/Tk as a widget library does come closer to addressing
> your wish. What is probably needed now is an event handler model that  
> allows
> you to write your events handlers in pure PL/I, rather than needing a Tcl
> wrapper. Perl/Tk, Python/TK, Rexx/Tk, ... all do this.
>
> Sicne my approach was to use VB6 to code the GUI, with the business  
> logic in
> PL/I, I never had the time or the need to address your requirement. Why
> don't you take on the project of coding a library to simplify use of Tk  
> from
> within PL/I?
>
> - Mark Yudkin
>
> "Alexander Damyanovich" <azdamyan@inetsonic.com> wrote in message
> news:rMQif.850$N7.510@fe13.usenetserver.com...
>> Excellent ideas for the paper and some fine discussions about this or  
>> that
>> feature of PL/I (as long as one ForTran fanatic is ignored).  What I'd
>> like to see however implemented as soon as possible is an expansion of  
>> the
>> excellent input/output features for paper and cards/prompts/etc. that
>> helped cement PL/I's reputation such that it could handle
>> Windows/Linux/whatever screen I/O such that C and its derivatives could  
>> be
>> *completely dispensed with*.  [Mark Yudkin's routines, however  
>> well-worked
>> on and supported, are not the answer as they still require one knowing C
>> and that junk!!!]  I wish to program in PL/I _without_ having to deal  
>> with
>> another language just because of the latter's being used with a specific
>> O/S!  Can't one develop a compiler that would allow generic I/O with  
>> menus
>> and all the goodies of Windows (or other interactive screen handling) -
>> surely it ought to be possible!
>>
>>
>
>

0
tom284 (1839)
11/30/2005 2:15:44 PM
On Tue, 29 Nov 2005 22:55:25 GMT, R. Vowels <robin_v@bigpond.com> wrote:

> As for PL/I for OS/2 of 1994 and subsequently, a function could return
> an aggregate result (i.e. an array). [page 10]  The Enterprise
> and VA PL/I compilers -derived from PL/I for OS/2- still do.
> Whether that was correct or not in 1993 when the paper was written,
> I don't know.

That might be a topic for the OP, the use of dope vectors.
0
tom284 (1839)
11/30/2005 2:18:43 PM
The paper to which I referred, PL/I for OS/2,
appears to be online.  I tried to verify that by downloading
it, but the site was not responding.
You might have more luck.
If you search in Google for "PL/I for OS/2" (without the quotes,
but with capital "I" not one "1") you will bring it up.


0
robin_v (2737)
11/30/2005 3:27:23 PM
robin wrote:
> 
> PL/I for OS/2 has a PM interface (a la windows).
> 

Yup.  I've used it.  It ain't pretty, but it works.  I understood the 
original poster to be asking for GUI support *in the language*, which I 
don't think is a good idea.  On the other hand, coding raw GUI logic in 
any language is a chore.

0
Peter_Flass (956)
12/1/2005 12:05:53 AM
Tom Linden wrote:

> You need SDL, shouldn't be too hard to port, written in PL/I.
> This was written almost 25 years ago!

1. Is the source for SDL available anywhere.  I thought it was a great 
idea years ago, and still not reproduced elsewhere.

2. Can SDL *import* declarations from C, PL/I, etc. and use them to 
build whatever its internal database is, or would you have to re-define 
all the structures in SDL.
> 

0
Peter_Flass (956)
12/1/2005 12:08:24 AM
Replying to my own post.  One option I am seriously considering is a 
compiler option to have the DISPLAY statement pop up a dialog box. 
Plain vanilla, it should be logically compatible with the standard use 
of display, but the user could tart it up by including formatting 
information in the message string, and possibly some OPTIONS() on the 
statement.

How about something like:
    "DISPLAY 'File <b>' || file_name || '</b> already exists.<br> ' ||
             'Press <b>REPLACE</b> to replace this file,<br>'       ||
             'or enter new file name and press <b>NEW</b>.'
       REPLY(new_file_name)
       OPTIONS( BUTTONS(REPLACE NEW) )
       EVENT(dialog_event); "

I haven't really thought this through yet, obviously, especially the 
OPTIONS stuff.  Opinions welcomed.

Peter Flass wrote:
> robin wrote:
> 
>>
>> PL/I for OS/2 has a PM interface (a la windows).
>>
> 
> Yup.  I've used it.  It ain't pretty, but it works.  I understood the 
> original poster to be asking for GUI support *in the language*, which I 
> don't think is a good idea.  On the other hand, coding raw GUI logic in 
> any language is a chore.
> 

0
Peter_Flass (956)
12/1/2005 1:08:31 AM
On Thu, 01 Dec 2005 00:08:24 GMT, Peter Flass <Peter_Flass@Yahoo.com>  
wrote:

> Tom Linden wrote:
>
>> You need SDL, shouldn't be too hard to port, written in PL/I.
>> This was written almost 25 years ago!
>
> 1. Is the source for SDL available anywhere.  I thought it was a great  
> idea years ago, and still not reproduced elsewhere.

Yes, Digital/Compaq relased the sources some years ago and they are  
included
in the freeware distribution, I have a copy locally which i can zip up
if you want.  You might want to get a VMS emulator to run on PC or linux
before attempting to move it to Windows.  BTW, the SCAN compiler was also
relased to freeware, and that uses the PL/I backend
>
> 2. Can SDL *import* declarations from C, PL/I, etc. and use them to  
> build whatever its internal database is, or would you have to re-define  
> all the structures in SDL.

No,  the definitions were in SDL and that would generate include files
for the appropriate languages.  As it turns out,  PL/I was largely the
motivation for creating SDL since its data types semantically subsume those
of most other languages.  The PL/I symbol table is an hierarchical  
tree-structure
data base whose  elements we call nodes.  An example therof follows both  
in SDL
and PL/I to give you a better idea of SDL

HAFNER> type DISK$PLI:[HERMES_USER3.MCKSAVE]ARRAYNODE.SDL
{ Copyright (c) 1989,1990,1991,1992,1993 by
{ Digital Equipment Corporation, Maynard, Massachusetts.
{ All rights reserved.
{
{ This software is furnished under a license and may be used and copied
{ only  in  accordance  of  the  terms  of  such  license  and with the
{ inclusion of the above copyright notice.  This software or any  other
{ copies thereof may not be provided or otherwise made available to any
{ other person.  No title to and  ownership of the  software is  hereby
{ transferred.
{
{ The information in this software is  subject to change without notice
{ and  should  not  be  construed  as a commitment by Digital Equipment
{ Corporation.
{
{ Digital assumes no responsibility for the use  or  reliability of its
{ software on equipment which is not supplied by Digital.
{
/*
/*
/*  002         26-JUL-1993     Peter Haynes
/*      Make modifications for DEC PL/I.  Made the refer_list structure
/*      a typedef.  This is because SDL produced a bad structure for the
/*      C language (.h) header file.
/*
MODULE ARRAYNODE;
/*
/* Define array nodes and related values.
/*
CONSTANT bound_k_size_long  EQUALS 4;
CONSTANT bound_k_size_word  EQUALS 8;
CONSTANT bound_k_size_byte  EQUALS 16;
/*
AGGREGATE array_node STRUCTURE;
    ntype                       WORD     ;
    array_spare_1               WORD;
    virtual_origin              LONGWORD ;/* NOTE: this is an address..
    element_size                LONGWORD ;/* conditional
    number_of_elements          LONGWORD ;/* conditional
    ref_list                    LONGWORD ;/* refer_list node id
    element_size_units          CHARACTER;
    multiplier_units            CHARACTER;/* Unit of offset term resulting  
 from indexing
    dimensions                  CHARACTER;
    total_dimensions            BYTE     ;
    constant_element_size       BITFIELD ;
    virtual_origin_is_ptr       BITFIELD ;
    star_extents                BITFIELD ;
    prol_extents                BITFIELD ;
    constant_virtual_origin     BITFIELD ;
    context_indexing            BITFIELD ;
    virtual_origin_is_offset    BITFIELD ;
    constant_number_of_elements BITFIELD ;
    array_spare_2 BITFIELD LENGTH 24;
    #array_size= .;
CONSTANT array_k_size_long  EQUALS #array_size/4;
CONSTANT array_k_size_word  EQUALS #array_size/2;
CONSTANT array_k_size_byte  EQUALS #array_size;
CONSTANT array_node_size    EQUALS #array_size/2;
CONSTANT max_array_byte_size EQUALS #array_size+8*16;
CONSTANT max_array_node_size EQUALS #array_size/2+8*8;
    bound         STRUCTURE DIMENSION 0:7;
       lower                    LONGWORD ;/* conditional
       upper                    LONGWORD ;/* conditional
       multiplier               LONGWORD ;/* conditional
       constant_lower           BITFIELD ;
       constant_upper           BITFIELD ;
       constant_multiplier      BITFIELD ;
       ref_lower                BITFIELD ;
       ref_upper                BITFIELD ;
       array_spare_3   BITFIELD LENGTH 27;
     END;
  END;
/*  The following structure is used by PL/I only.
/*
#agg_size= 0;
AGGREGATE agg_info STRUCTURE;
    ntype                       WORD     ;
    agg_info_spare_1            WORD     ;
    symbol                      LONGWORD ;/* modified
    locator                     LONGWORD ;/* modified
    total_size                  LONGWORD ;/* modified
    total_size_units            BYTE     ;
    bound_dimensions            BYTE     ;
    free_dimensions             BYTE     ;
    unconnected                 BITFIELD ;
    free_bits                   BITFIELD LENGTH 7;
    bound_subscripts            LONGWORD DIMENSION 8;/* modified
    number_of_elements          LONGWORD ;/* modified
    lbound                      LONGWORD DIMENSION 8;/* modified
    hbound                      LONGWORD DIMENSION 8;/* modified
#agg_size= .;
CONSTANT agg_k_size_long  EQUALS #agg_size/4;
CONSTANT agg_k_size_word  EQUALS #agg_size/2;
CONSTANT agg_k_size_byte  EQUALS #agg_size;
CONSTANT agg_info_size    EQUALS #agg_size/2;
   END;

#refer_size= 0;
AGGREGATE refer_list    STRUCTURE TYPEDEF DIMENSION 0:7;
    ntype                WORD;
    spare                CHARACTER LENGTH 2;
    lower                LONGWORD;
    upper                LONGWORD;
#refer_size= .;
CONSTANT refer_k_size_long EQUALS #refer_size/4;
CONSTANT refer_k_size_word EQUALS #refer_size/2;
CONSTANT refer_k_size_byte EQUALS #refer_size;
CONSTANT max_refer_size  EQUALS (#refer_size/2)*8;
    END;

END_MODULE;
HAFNER>
HAFNER> type DISK$PLI:[HERMES_USER3.MCKSAVE]ARRAYNODE.pli
/********************************************************************************************************************************/
/* Created: 27-FEB-1997 17:51:24 by OpenVMS SDL EV1-18     */
/* Source:  26-JUL-1993 15:46:12  
DPLI$:[DECPLI.BUILD.DPLIBUILD$1.COMPILER.ALPHA_ */
/********************************************************************************************************************************/
/*                                                                           
*/
/*                                                                           
*/
/*  002         26-JUL-1993     Peter  
Haynes                                */
/*      Make modifications for DEC PL/I.  Made the refer_list  
structure     */
/*      a typedef.  This is because SDL produced a bad structure for  
the    */
/*      C language (.h) header  
file.                                        */
/*                                                                           
*/

/*** MODULE ARRAYNODE ***/
/*                                                                           
*/
/* Define array nodes and related  
values.                                   */
/*                                                                           
*/
%replace bound_k_size_long by 4;
%replace bound_k_size_word by 8;
%replace bound_k_size_byte by 16;
/*                                                                           
*/
%replace array_k_size_long by 7;
%replace array_k_size_word by 14;
%replace array_k_size_byte by 28;
%replace array_node_size by 14;
%replace max_array_byte_size by 156;
%replace max_array_node_size by 78;

%replace s_array_node by 156;
dcl 1 array_node  based,
      2 ntype fixed binary(15),
      2 array_spare_1 fixed binary(15),
      2 virtual_origin fixed binary(31), /* NOTE: this is an  
address..       */
      2 element_size fixed binary(31),   /*  
conditional                      */
      2 number_of_elements fixed binary(31), /*  
conditional                  */
      2 ref_list fixed binary(31),       /* refer_list node  
id               */
      2 element_size_units character(1),
      2 multiplier_units character(1),   /* Unit of offset term resulting  
 from indexing */
      2 dimensions character(1),
      2 total_dimensions fixed binary(7),
      2 constant_element_size bit(1),
      2 virtual_origin_is_ptr bit(1),
      2 star_extents bit(1),
      2 prol_extents bit(1),
      2 constant_virtual_origin bit(1),
      2 context_indexing bit(1),
      2 virtual_origin_is_offset bit(1),
      2 constant_number_of_elements bit(1),
      2 array_spare_2 bit(24),
      2 bound (0:7) ,
       3 lower fixed binary(31),         /*  
conditional                      */
       3 upper fixed binary(31),         /*  
conditional                      */
       3 multiplier fixed binary(31),    /*  
conditional                      */
       3 constant_lower bit(1),
       3 constant_upper bit(1),
       3 constant_multiplier bit(1),
       3 ref_lower bit(1),
       3 ref_upper bit(1),
       3 array_spare_3 bit(27);
/*  The following structure is used by PL/I  
only.                           */
/*                                                                           
*/
%replace agg_k_size_long by 30;
%replace agg_k_size_word by 60;
%replace agg_k_size_byte by 120;
%replace agg_info_size by 60;

%replace s_agg_info by 120;
dcl 1 agg_info  based,
      2 ntype fixed binary(15),
      2 agg_info_spare_1 fixed binary(15),
      2 symbol fixed binary(31),         /*  
modified                         */
      2 locator fixed binary(31),        /*  
modified                         */
      2 total_size fixed binary(31),     /*  
modified                         */
      2 total_size_units fixed binary(7),
      2 bound_dimensions fixed binary(7),
      2 free_dimensions fixed binary(7),
      2 unconnected bit(1),
      2 free_bits bit(7),
      2 bound_subscripts (1:8) fixed binary(31), /*  
modified                 */
      2 number_of_elements fixed binary(31), /*  
modified                     */
      2 lbound (1:8) fixed binary(31),   /*  
modified                         */
      2 hbound (1:8) fixed binary(31);   /*  
modified                         */
%replace refer_k_size_long by 3;
%replace refer_k_size_word by 6;
%replace refer_k_size_byte by 12;
%replace max_refer_size by 48;

%replace s_refer_list by 96;
dcl 1 refer_list (0:7)  based,
      2 ntype fixed binary(15),
      2 spare character(2),
      2 lower fixed binary(31),
      2 upper fixed binary(31);
HAFNER>


>>
>

0
tom284 (1839)
12/1/2005 2:24:52 AM
Peter Flass wrote:

> Replying to my own post.  One option I am seriously considering is a 
> compiler option to have the DISPLAY statement pop up a dialog box. Plain 
> vanilla, it should be logically compatible with the standard use of 
> display, but the user could tart it up by including formatting 
> information in the message string, and possibly some OPTIONS() on the 
> statement.

I once used DISPLAY on an MVS system with a hardcopy system log printer
in the user area.  I was working on a program where one number would 
tell how well it was working, so I would DISPLAY that number.  It then 
appeared on the log a long time before printed output was available.

For today's systems a window probably does make more sense.

-- glen

0
gah (12851)
12/1/2005 7:36:21 AM
Isn't that a precursor to the various IDL compilers (DCE CORBA)?

In any case, it doesn't address Alex' complaint regarding the absence of a 
generic GUI model for PL/I.

"Tom Linden" <tom@kednos.com> wrote in message 
news:ops014kidrzgicya@hyrrokkin...
> You need SDL, shouldn't be too hard to port, written in PL/I.
> This was written almost 25 years ago!
> Tom
>
> HERMES> help sdl
>
> SDL
>
>
>    The VAX Structure Definition Language (VAX  SDL)  is  used  to  write
>    source  statements  that  describe  data  structures  and that can be
>    translated to source statements in other languages.  You can  include
>    the resulting output files in a corresponding target language program
>    for subsequent compilation.
>
>    Because  VAX  SDL  is  compiler-  and  language-independent,  it   is
>    particularly useful for maintaining multilanguage implementations.
>
>    Format:
>            SDL[/qualifier[...]] file-spec[/qualifier[...]],...
>
>    VAX SDL supports the following VMS languages:
>
>    o VAX Ada       o VAX BASIC   o VAX BLISS   o VAX C          o VAX 
> DATATRIEVE
>    o VAX FORTRAN   o VAX MACRO   o VAX Pascal  o VAXELN Pascal  o VAX PL/I
>
>
>
> On Wed, 30 Nov 2005 07:48:27 +0100, Mark Yudkin 
> <myudkinATcompuserveDOTcom@boingboing.org> wrote:
>
>> You don't need to _know_ C in order to use the Winows PL/I, but because 
>> the
>> MS documentation and most of the standard text books on the native API 
>> are
>> written for C programmers, it helps if you can read C declarations.
>>
>> None of this is compiler-related - the API is a call-level API. PL/I for
>> Windows provides support for that API (some of this as a result of 
>> specific
>> "requirements" I created).
>>
>> The problems with generic GUI models are the enormity of the task 
>> (consider
>> Java) and the look-and-feel mismatch of pure genericity (c.f. Java using
>> non-Windows widgets). That said, I provide support for Tcl/Tk (and much 
>> of
>> the X11 model) - perhaps the most frequently user of the standard widget
>> toolbox. Using Tcl/Tk as a widget library does come closer to addressing
>> your wish. What is probably needed now is an event handler model that 
>> allows
>> you to write your events handlers in pure PL/I, rather than needing a Tcl
>> wrapper. Perl/Tk, Python/TK, Rexx/Tk, ... all do this.
>>
>> Sicne my approach was to use VB6 to code the GUI, with the business 
>> logic in
>> PL/I, I never had the time or the need to address your requirement. Why
>> don't you take on the project of coding a library to simplify use of Tk 
>> from
>> within PL/I?
>>
>> - Mark Yudkin
>>
>> "Alexander Damyanovich" <azdamyan@inetsonic.com> wrote in message
>> news:rMQif.850$N7.510@fe13.usenetserver.com...
>>> Excellent ideas for the paper and some fine discussions about this or 
>>> that
>>> feature of PL/I (as long as one ForTran fanatic is ignored).  What I'd
>>> like to see however implemented as soon as possible is an expansion of 
>>> the
>>> excellent input/output features for paper and cards/prompts/etc. that
>>> helped cement PL/I's reputation such that it could handle
>>> Windows/Linux/whatever screen I/O such that C and its derivatives could 
>>> be
>>> *completely dispensed with*.  [Mark Yudkin's routines, however 
>>> well-worked
>>> on and supported, are not the answer as they still require one knowing C
>>> and that junk!!!]  I wish to program in PL/I _without_ having to deal 
>>> with
>>> another language just because of the latter's being used with a specific
>>> O/S!  Can't one develop a compiler that would allow generic I/O with 
>>> menus
>>> and all the goodies of Windows (or other interactive screen handling) -
>>> surely it ought to be possible!
>>>
>>>
>>
>>
> 


0
12/2/2005 9:55:08 AM
Here's a Windows DISPLAY without a reply (copied from some code of mine)

 ycpmsay: proc (title, prompt);
   dcl title  char (*),
       prompt char (*);

   call MessageBox (sysnull(),
                    trim (prompt, '', ' '), trim (title),
                    ior (MB_OK, MB_ICONINFORMATION, MB_SETFOREGROUND));
 end ycpmsay;

And here's a full-blown display with reply, including drag-and-drop file 
names (I think it's complete):

 /* some of these are superfluous - typical cut and paste effect */
 %include winbase;
 %include wingdi;
 %include winuser;
 %include commctrl;
 %include commdlg;
 %include shellapi;
 %include winreg;
 %include windowsx;

 dcl YCE_REG_KEY char
     value ('Software\Yudkin Consulting AG\Cogent/SQL for Windows');

 define structure
   1 DLG_STRUC,
     3 szTitle    char (MAX_TEXT_LENGTH) varz,
     3 szPrompt   char (260) varz,
     3 szReply    char (260) varz;

 ycpmdlg: proc (title, prompt, reply) returns (fixed bin (31));
   dcl title  char (*),
       prompt char (*),
       reply  char (*) var;

   dcl dlg_p               handle DLG_STRUC,
       code                fixed bin (31) init (0);

   dlg_p = new (: DLG_STRUC :);
   dlg_p => szTitle  = title;
   dlg_p => szPrompt = prompt;
   dlg_p => szReply  = reply;

   code = DialogBoxParam (YCPWTCM.HINSTANCE,
                          pli_p2z (MAKEINTRESOURCE (DLG_PROMPT)),
                          sysnull(), wp_ycpmdlg,
                          pli_h2b (dlg_p));
   reply = dlg_p => szReply;

   call plidelete (dlg_p);
   return (code);
 end ycpmdlg;

 wp_ycpmdlg: proc (hwnd, msg, wParam, lParam)
             returns (type BOOL byvalue optional) CALLBACK;
   dcl hwnd   type HWND,
       msg    type UINT,
       wParam type WPARAM,
       lParam type LPARAM;

   select (msg);
     HANDLE_DLGMSG (hwnd, WM_INITDIALOG, ycpmdlg_OnInitDialog);
     HANDLE_DLGMSG (hwnd, WM_COMMAND,    ycpmdlg_OnCommand);
     HANDLE_DLGMSG (hwnd, WM_DROPFILES,  ycpmdlg_OnDropfiles);
     HANDLE_DLGMSG (hwnd, WM_CLOSE,      ycpmdlg_OnClose);
     HANDLE_DLGMSG (hwnd, WM_DESTROY,    ycpmdlg_OnDestroy);

     otherwise ;
   end; /* select */
   return (FALSE);
 end wp_ycpmdlg;

 ycpmdlg_OnInitDialog: proc (hwnd, hwndFocus, dlgParm)
                       returns (type BOOL byvalue optional);
   dcl hwnd      type HWND   byvalue,
       hwndFocus type HWND   byvalue,
       dlgParm   type LPARAM byvalue;
   dcl dlg_p     handle DLG_STRUC;

   dlg_p = pli_b2h (DLG_STRUC, dlgParm);
   call SetWindowLong (hwnd, DWLP_USER, pli_h2b (dlg_p));
   call SendMessage (hwnd, WM_SETICON, ICON_BIG,
              binvalue (LoadIcon (GetWindowInstance(hwnd),
                                  pli_p2z (MAKEINTRESOURCE (1)))));
   call SendMessage (hwnd, WM_SETICON, ICON_SMALL,
              binvalue (LoadIcon (GetWindowInstance(hwnd),
                                  pli_p2z (MAKEINTRESOURCE (1)))));
   call SetWindowText (hwnd, dlg_p => szTitle);
   call SetDlgItemText (hwnd, TX_PROMPT, dlg_p => szPrompt);
   call SetDlgItemText (hwnd, EN_PROMPT, dlg_p => szReply);
   call DragAcceptFiles (hwnd, TRUE);
   call RestorePos (hwnd, 'ycpmdlg');
   call ShowWindow (hwnd, SW_RESTORE);
   call SetForegroundWindow (hwnd);
   return (TRUE);
 end ycpmdlg_OnInitDialog;

 ycpmdlg_OnCommand: proc (hwnd, id, hwndCtl, codeNotify);
   dcl hwnd       type HWND     byvalue,
       id         fixed bin(31) byvalue,
       hwndCtl    type HWND     byvalue,
       codeNotify type UINT     byvalue;
   dcl dlg_p handle DLG_STRUC;

   dlg_p = pli_b2h (DLG_STRUC, GetWindowLong (hwnd, DWLP_USER));
   select (id);
     when (IDOK) do;
       call GetDlgItemText (hwnd, EN_PROMPT,
                            dlg_p => szReply,
                            maxlength (dlg_p => szReply));
       call DragAcceptFiles (hwnd, FALSE);
       call SavePos (hwnd, 'ycpmdlg');
       call EndDialog (hwnd, IDOK);
     end;

     otherwise ;
   end;
 end ycpmdlg_OnCommand;

 ycpmdlg_OnDropfiles: proc (hwnd, hdrop);
   dcl hwnd  type HWND  byvalue,
       hdrop type HDROP byvalue;

   dcl szFileName char (MAX_PATH - 1) varz;

   call DragQueryFile (hdrop ,0, szFileName, maxlength (szFileName));
   call DragFinish (hdrop);

   call SetDlgItemText (hwnd, EN_PROMPT, szFileName);
 end ycpmdlg_OnDropfiles;

 ycpmdlg_OnClose: proc (hwnd);
   dcl hwnd  type HWND byvalue;

   dcl dlg_p   handle DLG_STRUC,
       hYceKey type HKEY,
       rc      type LONG,
       wndpl   type WINDOWPLACEMENT;

   dlg_p = pli_b2h (DLG_STRUC, GetWindowLong (hwnd, DWLP_USER));
   call GetDlgItemText (hwnd, EN_PROMPT,
                        dlg_p => szReply,
                        maxlength (dlg_p => szReply));
   call DragAcceptFiles (hwnd, FALSE);
   call SavePos (hwnd, 'ycpmdlg');
   call EndDialog (hwnd, IDCANCEL);
 end ycpmdlg_OnClose;

 ycpmdlg_OnDestroy: proc (hwnd);
   dcl hwnd type HWND byvalue;
   dcl dlg_p handle DLG_STRUC;

   dlg_p = pli_b2h (DLG_STRUC, GetWindowLong (hwnd, DWLP_USER));
   /* plus any cleanup logic */
 end ycpmdlg_OnDestroy;

And here's the RC file for the display (as created by the dialogue editor 
bundled with VA PL/I):

DLG_PROMPT DIALOG DISCARDABLE 89, 80, 285, 78
STYLE WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
CAPTION "Cogent/SQL for Windows - Input Request"
FONT 8, "MS Sans Serif"
BEGIN
  LTEXT           "Prompt",TX_PROMPT,4,3,276,36
  EDITTEXT        EN_PROMPT,4,42,276,14,ES_AUTOHSCROLL
  DEFPUSHBUTTON   "OK",IDOK,123,62,40,12,0
END

[don't forget to translate the IRC's generated .H into a .CPY]
- Mark Yudkin

"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
news:j2sjf.85129$JQ.65693@twister.nyroc.rr.com...
> Replying to my own post.  One option I am seriously considering is a 
> compiler option to have the DISPLAY statement pop up a dialog box. Plain 
> vanilla, it should be logically compatible with the standard use of 
> display, but the user could tart it up by including formatting information 
> in the message string, and possibly some OPTIONS() on the statement.
>
> How about something like:
>    "DISPLAY 'File <b>' || file_name || '</b> already exists.<br> ' ||
>             'Press <b>REPLACE</b> to replace this file,<br>'       ||
>             'or enter new file name and press <b>NEW</b>.'
>       REPLY(new_file_name)
>       OPTIONS( BUTTONS(REPLACE NEW) )
>       EVENT(dialog_event); "
>
> I haven't really thought this through yet, obviously, especially the 
> OPTIONS stuff.  Opinions welcomed.
>
> Peter Flass wrote:
>> robin wrote:
>>
>>>
>>> PL/I for OS/2 has a PM interface (a la windows).
>>>
>>
>> Yup.  I've used it.  It ain't pretty, but it works.  I understood the 
>> original poster to be asking for GUI support *in the language*, which I 
>> don't think is a good idea.  On the other hand, coding raw GUI logic in 
>> any language is a chore.
>>
> 


0
12/2/2005 1:39:33 PM
R. Vowels wrote in message ...

>In the mid-1990s I wrote a paper on the new features of
>PL/I for OS/2, that was published in the ACM Sigplan Notices.

"PL/I for OS/2" ACM Sigplan Notices, Vol. 31, No. 3, March 1996,
pp. 22-27.


0
robin_v (2737)
12/3/2005 1:42:29 PM
FSNole wrote in message <1132940103.169696.12330@z14g2000cwz.googlegroups.com>...
>I have to write a paper on PL/I for my programming languages course and
>one of the things I need to cover is interesting language features such
>as the treatment of gotos and labels, and ON conditions.  I haven't
>been able to find much information online about these topics and was
>wondering if anyone could suggest some resources I could use.  Thanks
>so much in advance.

You'll find quite a few references at:
http://liinwww.ira.uka.de/bibliography/




0
robin_v (2737)
12/3/2005 1:42:30 PM
"Tom Linden" <tom@kednos.com> wrote in message
news:ops0wryzgszgicya@hyrrokkin...
> ... Space, Defense, ... and other fields.
>
Very few, if any, defense applications are still written in PL/I.   From my, now
(long ago in the past) experience in space applications, I know of no
operational system
written in PL/I.

It would be interesting to know which applications in defense and space are
still executing PL/I programs -- if there are any.

Richard Riehle


0
adaworks2 (748)
12/19/2005 6:28:43 PM
"FSNole" <vogt@cs.fsu.edu> wrote in message
news:1133125838.129416.290400@g47g2000cwa.googlegroups.com...
> After researching some more.  I found this speech by Edsgar Dijkstra
> who stated in 1974, "I absolutely fail to see how we can keep our
> growing programs firmly within our intellectual grip when by its sheer
> baroqueness the programming language -our basic tool, mind you!-
> already escapes our intellectual control." in reference to PL/I
> (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html).
>  Any comments?
>
Dijkstra, in his later years, after making so many important contributions
to the science of computing, took to making pronouncements of this
sort about all kinds of things.

There have been attempts to create simple languages such as those
by Niklaus Wirth, beginning with Pascal and evolving through Oberon,
with Modula on the way.   At the other extreme there are such monstrosities
as C++ where each new version seems designed to compensate for some
irregularity in the existing standard.

A programming language must be internally consistent at every point in
its design and be free of surprise in its usage.   It should be free of
constructs
that cannot be checked by a well-written compiler.   A developer should
not be required to learn all of the language when the problems to be solved
require only a knowledge of some of the language.

The language modules need to support high cohesion, low coupling.   We should
be able to use the same language for our scientific and engineering problems and
our business data processing problems.   We should be able to tailor that
language
to many different kinds of applications.

I sometimes like to think of simplicity versus complexity by comparing the game
of Go to the game of Chess.   I play both games.    While Go is simple in its
rules,
it is complex in its strategies.  It is no less challenging than Chess.   Chess
is
restrictive in its rules for each piece and the complexities are substantial.
But chess
is no less a useful intellectual exercise than Go.

If a programming language has a well-formed set of consistent, non-contradictory
rules,
and those rules do not constantly offset each other in their effect, that is not
a problem.
If those rules lead to greater reliabilility early in the development process,
even better.
The C programming language is relatively simple in its rules but it is a horrid
language
when used for anything except small programs.   It is difficult to debug,
terrible to read
someone else's code, and so full of gotchas that I wonder why anyone continues
to
use it for important work.    There has to be a better language design than C.
There
are actually several.

I prefer Ada and Eiffel. Some of you prefer PL/I.   I am not sure whether PL/I
is the right
language since I have not written programs in it for over twenty years.
Perhaps it
has evolved to eliminate some of the gotchas that existed in earlier versions.
In a
different thread I asked some questions about the language in the interest of
updating
the content of a college class I teach on comparative programming languages.
Maybe
I will get some answers.

Richard Riehle


0
adaworks2 (748)
12/19/2005 6:51:43 PM
<adaworks@sbcglobal.net> wrote in message
news:3jDpf.36785$q%.15195@newssvr12.news.prodigy.com...
>
> There have been attempts to create simple languages such as those
> by Niklaus Wirth, beginning with Pascal

Such languages lacked features needed for the real world.
Pascal lacked string handling and decimal arithmetic,
and its I/O was flawed. It lacked the ** operator.
But its main drawback was the inability to handle
arrays of different sizes (aka dynamic arrays).
    A small language may appear to have attractions,
but it needs to have user-written software to provide
all those things that the language lacks, and in the end
the user finishes up with having to learn as much as a
larger language (by having to learn to use the additional
support packages as well as the language itself).

> and evolving through Oberon,
> with Modula on the way.   At the other extreme there are such monstrosities
> as C++ where each new version seems designed to compensate for some
> irregularity in the existing standard.
>
> A programming language must be internally consistent at every point in
> its design and be free of surprise in its usage.   It should be free of
> constructs
> that cannot be checked by a well-written compiler.   A developer should
> not be required to learn all of the language when the problems to be solved
> require only a knowledge of some of the language.
>
> The language modules need to support high cohesion, low coupling.   We should
> be able to use the same language for our scientific and engineering problems
and
> our business data processing problems.   We should be able to tailor that
> language
> to many different kinds of applications.

Sounds like PL/I.

> Richard Riehle
>


0
robin_v (2737)
12/20/2005 3:51:24 AM
On Mon, 19 Dec 2005 18:28:43 GMT, <adaworks@sbcglobal.net> wrote:

>
> "Tom Linden" <tom@kednos.com> wrote in message
> news:ops0wryzgszgicya@hyrrokkin...
>> ... Space, Defense, ... and other fields.
>>
> Very few, if any, defense applications are still written in PL/I.   From  
> my, now
> (long ago in the past) experience in space applications, I know of no
> operational system
> written in PL/I.

Why would you know?  PL/I is presently used both by NASA and ESA both on  
VAX and
Alpha.  NSA and the MoDs of several of our allies, particularly for secure
communications.  How do I know?  Because I support them.
>
> It would be interesting to know which applications in defense and space  
> are
> still executing PL/I programs -- if there are any.
>
> Richard Riehle
>
>

0
tom284 (1839)
12/21/2005 2:22:04 AM
"Tom Linden" <tom@kednos.com> wrote in message
news:ops133i2sizgicya@hyrrokkin...
> On Mon, 19 Dec 2005 18:28:43 GMT, <adaworks@sbcglobal.net> wrote:
>
> >
> > "Tom Linden" <tom@kednos.com> wrote in message
> > news:ops0wryzgszgicya@hyrrokkin...
> >> ... Space, Defense, ... and other fields.
> >>
> > Very few, if any, defense applications are still written in PL/I.   From
> > my, now
> > (long ago in the past) experience in space applications, I know of no
> > operational system
> > written in PL/I.
>
> Why would you know?

I am active in defense and defense related systems.   There has been no
call for PL/I in any of the systems I know about.

PL/I is presently used both by NASA and ESA both on
> VAX and
> Alpha.  NSA and the MoDs of several of our allies, particularly for secure
> communications.  How do I know?  Because I support them.
>
Fine.  I am sure there are some systems if you are supporting them.  I was
simply curious about the status of PL/I in these environments.  Is there new
development going on in PL/I or are you supporting legacy systems?

In another thread, in this forum, I asked for some information about the
modernization
of PL/I.   In particular, I am wondering about the support for specialization
through
inheritance (single or multiple), any concept analogous to the "class" in OOP,
polymorphism,
and dynamic binding.    Is there support for assertions such as Pre-, post-, and
invariant conditons?

Has PL/I kept evolving to correspond to the contemporary approaches to software
development?    Is it still more of a procedural approach or does it now support
object modeling?     I recall that the exception handling approach was more of a
"resumable" model than a "handle and exit" model.   Is that still true?   I know
we
used to have a workaround for that, but wonder if the workaround is still
required.

In looking at the current version of PL/I (I think it is the current version) I
see a lot
of syntatic concepts adopted from C.   I am a little suprised to see that the =
is
still overloaded and wonder whether that can give one trouble as it would in C
or C++ when used in ambiguous ways.

Finally, why would one choose PL/I instead of C++, Ada, Eiffel, or Java?  I can
see that PL/I has a nice set of interoperabilty options when one is programming
an IBM mainframe and needs to use CICS.  When I look at the exxample code,
typically posted to illustrate PL/I solutions, it seems a little bit
old-fashioned.

I teach a graduate course in comparative programming languages so I am
interested
in reliable information that would be of value to my students.   Unfortunately,
most of
the contemporary textbooks on comparative programming languages are not very
complimentary of PL/I.   Most authors treat it as if it were a quaint language
of the
past that introduced some interesting ideas, but which has little to offer in
modern
times.   Even COBOL and Ada continue to evolve.   There is an outstanding
question
about the evolution of PL/I in terms of modern programming styles.

Tom, I think you and I met at a seminar in Silicon Valley around 1998.   I doubt
whether you remember me, but you did give me a business card at that time.

Richard Riehle


0
adaworks2 (748)
12/22/2005 7:43:00 AM
On Thu, 22 Dec 2005 07:43:00 GMT, <adaworks@sbcglobal.net> wrote:

>
> "Tom Linden" <tom@kednos.com> wrote in message
> news:ops133i2sizgicya@hyrrokkin...
>> On Mon, 19 Dec 2005 18:28:43 GMT, <adaworks@sbcglobal.net> wrote:
>>
>> >
>> > "Tom Linden" <tom@kednos.com> wrote in message
>> > news:ops0wryzgszgicya@hyrrokkin...
>> >> ... Space, Defense, ... and other fields.
>> >>
>> > Very few, if any, defense applications are still written in PL/I.    
>> From
>> > my, now
>> > (long ago in the past) experience in space applications, I know of no
>> > operational system
>> > written in PL/I.
>>
>> Why would you know?
>
> I am active in defense and defense related systems.   There has been no
> call for PL/I in any of the systems I know about.
>
> PL/I is presently used both by NASA and ESA both on
>> VAX and
>> Alpha.  NSA and the MoDs of several of our allies, particularly for  
>> secure
>> communications.  How do I know?  Because I support them.
>>
> Fine.  I am sure there are some systems if you are supporting them.  I  
> was
> simply curious about the status of PL/I in these environments.  Is there  
> new
> development going on in PL/I or are you supporting legacy systems?

I only support the compiler.  Our customers are doing new development (NSA)
but mostly support and enhancement of existing systems.

>
> In another thread, in this forum, I asked for some information about the
> modernization
> of PL/I.   In particular, I am wondering about the support for  
> specialization
> through
> inheritance (single or multiple), any concept analogous to the "class"  
> in OOP,
> polymorphism,
> and dynamic binding.    Is there support for assertions such as Pre-,  
> post-, and
> invariant conditons?

I am not convinced that introducing fashionable nomenclature advances the
state of the art of programming.  The GENERIC attribute actually provides
a form of overloading, but with stronger typing.  Lexical scoping is a form
of inheritance, LIKE and TYPE provide for type inheritance  CONTOLLED  
provides
a mechanism for data instantiation and stacking.

I don't what Pre- Post .. is.

>
> Has PL/I kept evolving to correspond to the contemporary approaches to  
> software
> development?    Is it still more of a procedural approach or does it now  
> support
> object modeling?     I recall that the exception handling approach was  
> more of a
> "resumable" model than a "handle and exit" model.   Is that still  
> true?   I know
> we
> used to have a workaround for that, but wonder if the workaround is still
> required.
>
> In looking at the current version of PL/I (I think it is the current  
> version) I
> see a lot
> of syntatic concepts adopted from C.

Not in our compiler, we do support OPTION(C) on PROC, ENTRY and DECLARE
statements, facilitating seamless binding with C programs
  I am a little suprised to see
> that the =
> is
> still overloaded and wonder whether that can give one trouble as it  
> would in C
> or C++ when used in ambiguous ways.

There is no trouble here,  it is used as it would be in natural language
>
> Finally, why would one choose PL/I instead of C++, Ada, Eiffel, or Java?
Lower development costs, cheaper to maintain, higher level of abstraction.
Objects in C++ become diffuse in meaning with the passage of time and so  
their
reusability becomes questionable as the sematics become increasingly
complex.  Ada has many of the advantages of PL/I, but lacks an interest
outside of government mandated programs, i.e. doesn't stand the market  
test.
Eiffel is a curiosity.  Java like C is too low level.  BTW, I was  
disappointed
to see the Microsoft did such a poor job defining .NET particularly since
Cutler was intimately familiar with the PL/I abstract machine, a historical
progenitor of which was Multics PL/I.
I can
> see that PL/I has a nice set of interoperabilty options when one is  
> programming
> an IBM mainframe and needs to use CICS.  When I look at the exxample  
> code,
> typically posted to illustrate PL/I solutions, it seems a little bit
> old-fashioned.
fashion.  QED
>
> I teach a graduate course in comparative programming languages so I am
> interested
> in reliable information that would be of value to my students.    
> Unfortunately,
> most of
> the contemporary textbooks on comparative programming languages are not  
> very
> complimentary of PL/I.   Most authors treat it as if it were a quaint  
> language
> of the
> past that introduced some interesting ideas, but which has little to  
> offer in
> modern
> times.

Well, it may be regarded as quaint, but you won't see buffer overrun  
exploits.
Of course, you must specify in which enviroment it is being used, the  
weakest link
argument.  PL/I on VMS is as good as it gets, which is perhaps one reason
many defense organizations use it for communications applications.

Even COBOL and Ada continue to evolve.   There is an outstanding
> question
> about the evolution of PL/I in terms of modern programming styles.

Well, Richard, before I retire, I will make some major changes to PL/I, but
I will do it more in the spirit of VDL,  Also I will make SDL generally  
available
to facilitate interoperability of diverse programming languages.

Now a question for you, what would you find useful to add to PL/I or Ada?
>
> Tom, I think you and I met at a seminar in Silicon Valley around 1998.    
> I doubt
> whether you remember me, but you did give me a business card at that  
> time.

Yes, I do remember, but I thought it was earlier.  What was on the  
business card?
It was sponsored by Meridien as I recall, I still have  the sources  
somewhere of
their Ada and Pascal compilers.
>
> Richard Riehle
>
>

0
tom284 (1839)
12/22/2005 4:43:46 PM
Someone (Peter Elderon?) wrote a paper a while ago abou object-oriented 
extensions to PL/I.  If you can't find it, I could probably dig up a 
copy next week.

adaworks@sbcglobal.net wrote:
> "Tom Linden" <tom@kednos.com> wrote in message
> news:ops133i2sizgicya@hyrrokkin...
> 
>>On Mon, 19 Dec 2005 18:28:43 GMT, <adaworks@sbcglobal.net> wrote:
>>
>>
>>>"Tom Linden" <tom@kednos.com> wrote in message
>>>news:ops0wryzgszgicya@hyrrokkin...
>>>
>>>>... Space, Defense, ... and other fields.
>>>>
>>>
>>>Very few, if any, defense applications are still written in PL/I.   From
>>>my, now
>>>(long ago in the past) experience in space applications, I know of no
>>>operational system
>>>written in PL/I.
>>
>>Why would you know?
> 
> 
> I am active in defense and defense related systems.   There has been no
> call for PL/I in any of the systems I know about.
> 
> PL/I is presently used both by NASA and ESA both on
> 
>>VAX and
>>Alpha.  NSA and the MoDs of several of our allies, particularly for secure
>>communications.  How do I know?  Because I support them.
>>
> 
> Fine.  I am sure there are some systems if you are supporting them.  I was
> simply curious about the status of PL/I in these environments.  Is there new
> development going on in PL/I or are you supporting legacy systems?
> 
> In another thread, in this forum, I asked for some information about the
> modernization
> of PL/I.   In particular, I am wondering about the support for specialization
> through
> inheritance (single or multiple), any concept analogous to the "class" in OOP,
> polymorphism,
> and dynamic binding.    Is there support for assertions such as Pre-, post-, and
> invariant conditons?
> 
> Has PL/I kept evolving to correspond to the contemporary approaches to software
> development?    Is it still more of a procedural approach or does it now support
> object modeling?     I recall that the exception handling approach was more of a
> "resumable" model than a "handle and exit" model.   Is that still true?   I know
> we
> used to have a workaround for that, but wonder if the workaround is still
> required.
> 
> In looking at the current version of PL/I (I think it is the current version) I
> see a lot
> of syntatic concepts adopted from C.   I am a little suprised to see that the =
> is
> still overloaded and wonder whether that can give one trouble as it would in C
> or C++ when used in ambiguous ways.
> 
> Finally, why would one choose PL/I instead of C++, Ada, Eiffel, or Java?  I can
> see that PL/I has a nice set of interoperabilty options when one is programming
> an IBM mainframe and needs to use CICS.  When I look at the exxample code,
> typically posted to illustrate PL/I solutions, it seems a little bit
> old-fashioned.
> 
> I teach a graduate course in comparative programming languages so I am
> interested
> in reliable information that would be of value to my students.   Unfortunately,
> most of
> the contemporary textbooks on comparative programming languages are not very
> complimentary of PL/I.   Most authors treat it as if it were a quaint language
> of the
> past that introduced some interesting ideas, but which has little to offer in
> modern
> times.   Even COBOL and Ada continue to evolve.   There is an outstanding
> question
> about the evolution of PL/I in terms of modern programming styles.
> 
> Tom, I think you and I met at a seminar in Silicon Valley around 1998.   I doubt
> whether you remember me, but you did give me a business card at that time.
> 
> Richard Riehle
> 
> 

0
Peter_Flass (956)
12/22/2005 7:06:21 PM
On Thu, 22 Dec 2005 19:06:21 GMT, Peter Flass <Peter_Flass@Yahoo.com>  
wrote:

> Someone (Peter Elderon?) wrote a paper a while ago abou object-oriented  
> extensions to PL/I.  If you can't find it, I could probably dig up a  
> copy next week.
>

Thanks, Peter, I would appreciate that.  BTW, do you find useful attributed
pointers?
0
tom284 (1839)
12/22/2005 7:38:40 PM
Tom,

Thanks for a thoughtful and informative reply.

May I suggest that someone in the PL/I community get in touch
with some or all of the authors of comparative programming books
to update them on the current status of PL/I.

I personally do not like C++.  The sign on my office door proclaims,
"C++ is its own Virus."   I do continue to like Ada, and Ada goes
through a very orderly ISO update process so the Ada 2005 version,
backward compatible with earlier versions, does continue to evolve.

Java leaves me a little bit unexcited.   I do like functional languages for
some things.   I also like Eiffel.

Is there an ISO standard for PL/I.   I suppose I could look this up but
I suspect others in this forum might like to know too.

The pre-, post-, and invariant assertions derive from the early work of
Tony Hoare.  Few languages include them explicitly, but there would be
no reason why PL/I could not since there is an exception handling facility
built in to the language.   Eiffel includes them as: precondition = require and
postcondition = ensure.  Invariant is simply called invariant.

Assertions, intelligently done, are a good feature to add to a programming
language when reliability is a concern.   C++ has an "assert" option but it
is a disappointing feature that falls far short of what ought to have been.

I am wondering about LIKE and TYPE in PL/I.   Does this mean we can
extend an existing design without breaking it?    Bertrand Meyer introduces
a principle called the "open-closed principle."   This means a module is
closed to modification even as it is open to non-invasive extension.

In reply to your question about what I would like to see added to PL/I, I
think assertions, as described above, would be at the top of the list.  There is
also a great feature that was added to ANSI-85 COBOL that no other
language has:  the EVALUATE statement.  This is a great feature for simplifying
the communication between user, designer, and programmer.

Also, I'll be looking forward to seeing some of the replies that discuss the
status
of object technology and PL/I.

Thanks again,

Richard Riehle


0
adaworks2 (748)
12/22/2005 11:56:22 PM
I think you're refering to:

http://groups.google.com/group/comp.lang.pl1/browse_thread/thread/f943a05307627900/1c6f906147d260bd?lnk=st&q=group%3Acomp.lang.pl1+insubject%3APtere+insubject%3AElderon's+insubject%3AOO-PL%2FI+insubject%3Apresentation.&rnum=1&hl=en#1c6f906147d260bd

Hope this helps,
Jeff


Tom Linden said the following on 12/22/2005 02:38 PM:
> On Thu, 22 Dec 2005 19:06:21 GMT, Peter Flass <Peter_Flass@Yahoo.com>  
> wrote:
> 
>> Someone (Peter Elderon?) wrote a paper a while ago abou 
>> object-oriented  extensions to PL/I.  If you can't find it, I could 
>> probably dig up a  copy next week.
>>
> 
> Thanks, Peter, I would appreciate that.  BTW, do you find useful attributed
> pointers?
0
jeffos2 (14)
12/23/2005 12:54:21 AM
"Jeffery Swagger" <jeffos2@adelphia.net> wrote in message
news:Ssednd4F64oj1zbeRVn-gA@adelphia.com...
> I think you're refering to:
>
>
http://groups.google.com/group/comp.lang.pl1/browse_thread/thread/f943a05307627900/1c6f906147d260bd?lnk=st&q=group%3Acomp.lang.pl1+insubject%3APtere+insubject%3AElderon's+insubject%3AOO-PL%2FI+insubject%3Apresentation.&rnum=1&hl=en#1c6f906147d260bd
>
This is a very interesting document.    How much of it is implemented?   Will it
become part of an ISO standard PL/I?

There are some things that are not entirely clear.  Are objects of classes, when
passed
as parameters, by reference or by value?  Or does one need to set up the kind of
silly
mechanisms that characterize C++?

Is a class implemented where it is declared or may it implemented in a separate
compilation
unit (a la Ada)?

Is there an expectation of full polymorphism?   Not just overloading, but
dynamic binding
in support of polymorphism.

Can we expect an assertion model similar to that in Eiffel?    That would go a
long way
toward making PL/I a strong contender for modern software engineering.

Richard Riehle


0
adaworks2 (748)
12/23/2005 6:05:04 PM
"robin" <robin_v@bigpond.com> wrote in message
news:Okwif.5518$ea6.3265@news-server.bigpond.net.au...
>     Ada suffered from the same deficiency until it
> was recognized that you really do need to have dynamic
> arrays (unconstrained).
>
Ada has had unconstrained arrays from its first (1983) version through
the current (soon to be 2005) version.

Richard Riehle


0
adaworks2 (748)
12/23/2005 11:35:16 PM
"robin" <robin_v@bigpond.com> wrote in message
news:0dLpf.61827$V7.36800@news-server.bigpond.net.au...
> <adaworks@sbcglobal.net> wrote in message
> >
> > A programming language must be internally consistent at every point in
> > its design and be free of surprise in its usage.   It should be free of
> > constructs  that cannot be checked by a well-written compiler.   A developer
should
> > not be required to learn all of the language when the problems to be solved
> > require only a knowledge of some of the language.
> >
> > The language modules need to support high cohesion, low coupling.   We
should
> > be able to use the same language for our scientific and engineering problems
> > and our business data processing problems.   We should be able to tailor
that
> > language to many different kinds of applications.
>
> Sounds like PL/I.
>
Perhaps.  I was thinking of Ada.

Richard Riehle


0
adaworks2 (748)
12/23/2005 11:38:44 PM
On Fri, 23 Dec 2005 18:05:04 GMT, <adaworks@sbcglobal.net> wrote:

>
> "Jeffery Swagger" <jeffos2@adelphia.net> wrote in message
> news:Ssednd4F64oj1zbeRVn-gA@adelphia.com...
>> I think you're refering to:
>>
>>
> http://groups.google.com/group/comp.lang.pl1/browse_thread/thread/f943a05307627900/1c6f906147d260bd?lnk=st&q=group%3Acomp.lang.pl1+insubject%3APtere+insubject%3AElderon's+insubject%3AOO-PL%2FI+insubject%3Apresentation.&rnum=1&hl=en#1c6f906147d260bd
>>
> This is a very interesting document.    How much of it is implemented?    
> Will it
> become part of an ISO standard PL/I?
>
> There are some things that are not entirely clear.  Are objects of  
> classes, when
> passed
> as parameters, by reference or by value?  Or does one need to set up the  
> kind of
> silly
> mechanisms that characterize C++?

Well, unless they are changing it,  the default is by reference, by value  
in PL/I
means making a local copy and passing a pointer to the copy, unlike C  
which passes
the thing itself on the stack.
>
> Is a class implemented where it is declared or may it implemented in a  
> separate
> compilation
> unit (a la Ada)?
>
> Is there an expectation of full polymorphism?   Not just overloading, but
> dynamic binding
> in support of polymorphism.
>
> Can we expect an assertion model similar to that in Eiffel?    That  
> would go a
> long way
> toward making PL/I a strong contender for modern software engineering.
>
> Richard Riehle
>
>

0
tom284 (1839)
12/24/2005 2:48:53 PM
> How much of it is implemented?

Believe it or not, it's all been implemented, albeit with some minor 
syntactic differences, in the Windows compiler. It has not been documented, 
and I don't know why Peter Elderon is so reluctant to announce and document 
it. I do know that it does not generate a C++-compatible vtable, which makes 
it unusable for mapping COM.

<adaworks@sbcglobal.net> wrote in message 
news:k%Wqf.46599$6e1.1427@newssvr14.news.prodigy.com...
>
> "Jeffery Swagger" <jeffos2@adelphia.net> wrote in message
> news:Ssednd4F64oj1zbeRVn-gA@adelphia.com...
>> I think you're refering to:
>>
>>
> http://groups.google.com/group/comp.lang.pl1/browse_thread/thread/f943a05307627900/1c6f906147d260bd?lnk=st&q=group%3Acomp.lang.pl1+insubject%3APtere+insubject%3AElderon's+insubject%3AOO-PL%2FI+insubject%3Apresentation.&rnum=1&hl=en#1c6f906147d260bd
>>
> This is a very interesting document.    How much of it is implemented? 
> Will it
> become part of an ISO standard PL/I?
>
> There are some things that are not entirely clear.  Are objects of 
> classes, when
> passed
> as parameters, by reference or by value?  Or does one need to set up the 
> kind of
> silly
> mechanisms that characterize C++?
>
> Is a class implemented where it is declared or may it implemented in a 
> separate
> compilation
> unit (a la Ada)?
>
> Is there an expectation of full polymorphism?   Not just overloading, but
> dynamic binding
> in support of polymorphism.
>
> Can we expect an assertion model similar to that in Eiffel?    That would 
> go a
> long way
> toward making PL/I a strong contender for modern software engineering.
>
> Richard Riehle
>
> 


0
12/25/2005 10:48:22 AM
Tom Linden wrote:
> On Thu, 22 Dec 2005 19:06:21 GMT, Peter Flass <Peter_Flass@Yahoo.com>  
> wrote:
> 
>> Someone (Peter Elderon?) wrote a paper a while ago abou 
>> object-oriented  extensions to PL/I.  If you can't find it, I could 
>> probably dig up a  copy next week.
>>
> 
> Thanks, Peter, I would appreciate that.  BTW, do you find useful attributed
> pointers?

Short answer: no.  Long answer: I feel they clutter up programs with 
unnecessary casts.  To get the same effect, I've been including a 
"prototypes" section in my data declarations.  Instead of C's " char *p" 
I'll do the usual "dcl p ptr", and then under "prototypes" "dcl c1 
char(1) based", and then reference p->c1.  I think this is cleaner and 
requires less rigamarole.

I'll look for the paper on Wed.,  apparently I don't have a copy with my 
other PL/I doc at home.

0
Peter_Flass (956)
12/27/2005 12:56:24 AM
adaworks@sbcglobal.net wrote:

> 
> Is there an ISO standard for PL/I.   I suppose I could look this up but
> I suspect others in this forum might like to know too.

PL/I is ANSI standard X3.53-1976 (rev 1998): Full language, and ANSI 
Standard X3.74-1987: "Subset G", which is not a proper subset.  Most 
current compilers implement both.  I don't know offhand what the 
corresponding ISO standards are, but I believe ISO has endorsed both 
standards without change.

> 
> In reply to your question about what I would like to see added to PL/I, I
> think assertions, as described above, would be at the top of the list.  There is
> also a great feature that was added to ANSI-85 COBOL that no other
> language has:  the EVALUATE statement.  This is a great feature for simplifying
> the communication between user, designer, and programmer.
> 

I'm not an authority on assertions, but I believe much of this 
functionality can be implemented using the preprocessor, which is much 
more capable than C's preprocessor.

0
Peter_Flass (956)
12/27/2005 1:10:23 AM
That may be it, I can't recall exactly.

Jeffery Swagger wrote:

> I think you're refering to:
> 
> http://groups.google.com/group/comp.lang.pl1/browse_thread/thread/f943a05307627900/1c6f906147d260bd?lnk=st&q=group%3Acomp.lang.pl1+insubject%3APtere+insubject%3AElderon's+insubject%3AOO-PL%2FI+insubject%3Apresentation.&rnum=1&hl=en#1c6f906147d260bd 
> 
> 
> Hope this helps,
> Jeff
> 
> 
> Tom Linden said the following on 12/22/2005 02:38 PM:
> 
>> On Thu, 22 Dec 2005 19:06:21 GMT, Peter Flass <Peter_Flass@Yahoo.com>  
>> wrote:
>>
>>> Someone (Peter Elderon?) wrote a paper a while ago abou 
>>> object-oriented  extensions to PL/I.  If you can't find it, I could 
>>> probably dig up a  copy next week.
>>>
>>
>> Thanks, Peter, I would appreciate that.  BTW, do you find useful 
>> attributed
>> pointers?

0
Peter_Flass (956)
12/27/2005 1:12:43 AM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:3w0sf.56016$XC4.7435@twister.nyroc.rr.com...
>
> I'm not an authority on assertions, but I believe much of this
> functionality can be implemented using the preprocessor, which is much
> more capable than C's preprocessor.
>
I rather doubt that.   Moreover, the C preprocessor is not a particularly
good standard against which to measure anything.   And C++ assertions
are a poor substitute for a good assertion mechanism.

If you want to know more about assertions, particularly pre-conditions,
post-conditions, and invariants, you might take a look at how this
is done in Eiffel.

Post-conditions, for example, have a direct relationship to weakest
pre-conditions.  This needs to be evaluated by a fairly sophisticated
set of compiler capabilities.   It also has to be tied to the exception
handling mechanism in the language.

Assertions can be handled by pre-processors, but not in any way where
the relationships can be consistently applied across the full complexity of
the corresponding program.

You might also read the work of C.A.R. (Tony) Hoare, the original proponent
of this notion for program correctness.

Richard Riehle


0
adaworks2 (748)
12/27/2005 7:27:25 AM
<adaworks@sbcglobal.net> wrote in message
news:x16sf.1393$UF3.1115@newssvr25.news.prodigy.net...
>
> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
> news:3w0sf.56016$XC4.7435@twister.nyroc.rr.com...
> >
> > I'm not an authority on assertions, but I believe much of this
> > functionality can be implemented using the preprocessor, which is much
> > more capable than C's preprocessor.
> >
> I rather doubt that.   Moreover, the C preprocessor is not a particularly
> good standard against which to measure anything.   And C++ assertions
> are a poor substitute for a good assertion mechanism.
>
> If you want to know more about assertions, particularly pre-conditions,
> post-conditions, and invariants, you might take a look at how this
> is done in Eiffel.
>
> Post-conditions, for example, have a direct relationship to weakest
> pre-conditions.  This needs to be evaluated by a fairly sophisticated
> set of compiler capabilities.   It also has to be tied to the exception
> handling mechanism in the language.
>
> Assertions can be handled by pre-processors, but not in any way where
> the relationships can be consistently applied across the full complexity of
> the corresponding program.

With PL/I's preprocessor, an ASSERT statement can be implemented.
As well, this can use the exception-handling mechanism.


0
robin_v (2737)
12/27/2005 10:51:32 PM
<adaworks@sbcglobal.net> wrote in message
news:x16sf.1393$UF3.1115@newssvr25.news.prodigy.net...
>
> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
> news:3w0sf.56016$XC4.7435@twister.nyroc.rr.com...
> >
> > I'm not an authority on assertions, but I believe much of this
> > functionality can be implemented using the preprocessor, which is much
> > more capable than C's preprocessor.
> >
> I rather doubt that.

Doubt all you like, but it's a fact.


0
robin_v (2737)
12/27/2005 10:51:34 PM
"robin" <robin_v@bigpond.com> wrote in message
news:Wzjsf.118464$V7.12506@news-server.bigpond.net.au...
> <adaworks@sbcglobal.net> wrote in message
> news:x16sf.1393$UF3.1115@newssvr25.news.prodigy.net...
> >
> > "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
> > news:3w0sf.56016$XC4.7435@twister.nyroc.rr.com...
> > >
> > > I'm not an authority on assertions, but I believe much of this
> > > functionality can be implemented using the preprocessor, which is much
> > > more capable than C's preprocessor.
> > >
> > I rather doubt that.
>
> Doubt all you like, but it's a fact.
>
I do not doubt that it is more powerful than C's preprocessor.  My doubts
have to do with the ability to get the full effect of pre-conditions,
post-conditions,
and invariants using preprocessor directives and macros.

This is a far more sophisticated topic than might appear to be the case.  For
a good example of this look at the Eiffel model.   Further, since standard PL/I
does not seem to support object technology, the capability for invariants
is likely to be rather limited.   Also, a preprocessor approach usually demands
too much care to ensure that assertions do not cancel each other out.

It is no sin to admit the shortcomings of one's favorite language.  Every
language
has its shortcomings and failure to acknowledge them borders on zealotry rather
than reason.

Richard Riehle
>


0
adaworks2 (748)
12/28/2005 8:21:41 AM
On Wed, 28 Dec 2005 08:21:41 GMT, <adaworks@sbcglobal.net> wrote:

> I do not doubt that it is more powerful than C's preprocessor.  My doubts
> have to do with the ability to get the full effect of pre-conditions,
> post-conditions,
> and invariants using preprocessor directives and macros.

Richard,  could you provide, for my education, examples.
0
tom284 (1839)
12/28/2005 1:58:22 PM
I found a copy at http://www.users.bigpond.com/robin_v/pli_oo.htm.  I
don't think I have Peter's original

Tom Linden wrote:
> On Thu, 22 Dec 2005 19:06:21 GMT, Peter Flass <Peter_Flass@Yahoo.com>
> wrote:
>
> > Someone (Peter Elderon?) wrote a paper a while ago abou object-oriented
> > extensions to PL/I.  If you can't find it, I could probably dig up a
> > copy next week.
> >
>
> Thanks, Peter, I would appreciate that.  BTW, do you find useful attributed
> pointers?

0
Peter_Flass (956)
12/28/2005 6:37:23 PM
<adaworks@sbcglobal.net> wrote in message
news:pWrsf.47868$tV6.18351@newssvr27.news.prodigy.net...
>
> "robin" <robin_v@bigpond.com> wrote in message
> news:Wzjsf.118464$V7.12506@news-server.bigpond.net.au...
> > <adaworks@sbcglobal.net> wrote in message
> > news:x16sf.1393$UF3.1115@newssvr25.news.prodigy.net...
> > >
> > > "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
> > > news:3w0sf.56016$XC4.7435@twister.nyroc.rr.com...
> > > >
> > > > I'm not an authority on assertions, but I believe much of this
> > > > functionality can be implemented using the preprocessor, which is much
> > > > more capable than C's preprocessor.
> > > >
> > > I rather doubt that.
> >
> > Doubt all you like, but it's a fact.
> >
> I do not doubt that it is more powerful than C's preprocessor.

You can be sure of that.

>  My doubts
> have to do with the ability to get the full effect of pre-conditions,
> post-conditions,
> and invariants using preprocessor directives and macros.
>
> This is a far more sophisticated topic than might appear to be the case.  For
> a good example of this look at the Eiffel model.

PL/I is not Eiffel.

> Further, since standard PL/I
> does not seem to support object technology, the capability for invariants
> is likely to be rather limited.   Also, a preprocessor approach usually
demands
> too much care to ensure that assertions do not cancel each other out.

That is, of course, general waffle.  Assertions can be implemented
trivially in PL/I via the preprocessor.

> It is no sin to admit the shortcomings of one's favorite language.  Every
> language
> has its shortcomings and failure to acknowledge them borders on zealotry
rather
> than reason.

You have described yourself.

> Richard Riehle


0
robin_v (2737)
12/28/2005 11:10:31 PM
On Wed, 28 Dec 2005 08:21:41 GMT, <adaworks@sbcglobal.net> wrote:

> I do not doubt that it is more powerful than C's preprocessor.  My doubts
> have to do with the ability to get the full effect of pre-conditions,
> post-conditions,
> and invariants using preprocessor directives and macros.

OK, I know now what you are after, I had a look at
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

In my view what they have done is to reinvent the signalling
mechanism of PL/I, which is, in fact, more powerful.  Some assertions,
e.g., range and bounds can be implicitly accomplished in PL/I; whereas,
in languages with lower level of abstraction like C or Java in this case
they must be made explicit.  Remember in PL/I, CONDITION (which is a
generalized form for assertion) is a data type, and well written PL/I
code should abound with ON-Conditions both predefined and user defined,
thereby leading to the possibility of writing fault tolerant, and
possibly self correcting code.  Of course, very few programmers lack
the mental capacity or the drive to think about contingency or
fault-tree analysis, which is readily amenable to algebraic methods
and probablistic models, which is somthing we were taught (on the job)
40 years ago before the invention of Computer Science curricula, the
latter. of which, seem to be preoccupied with creating nomenclature,
reminiscent of Spengler's concept of civilization.

I had somwhere a paper called something like "On the PL/I Signalling
Mechanism" Don't recall the author, but i think it was in Sigplan, maybe
late 60's,  Peter probably has a copy.

Tom
0
tom284 (1839)
12/29/2005 1:49:31 AM
"Tom Linden" <tom@kednos.com> wrote in message
news:ops2ivctcgzgicya@hyrrokkin...
>
> OK, I know now what you are after, I had a look at
> http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
>
> In my view what they have done is to reinvent the signalling
> mechanism of PL/I, which is, in fact, more powerful.  Some assertions,
> e.g., range and bounds can be implicitly accomplished in PL/I; whereas,
> in languages with lower level of abstraction like C or Java in this case
> they must be made explicit.  Remember in PL/I, CONDITION (which is a
> generalized form for assertion) is a data type, and well written PL/I
> code should abound with ON-Conditions both predefined and user defined,
> thereby leading to the possibility of writing fault tolerant, and
> possibly self correcting code.

I don't remember much about the signalling mechanism in PL/I.  I do recall
CONDITION, but when I programmed in PL/I I was not using it except
in very elementary forms, mostly the predefined forms.

At the method level, a pre-condition is a boolean statement that must be
true before the called method (procedure/function) will be successful.  A
post-condition is a boolean statement describing what must be true when
the method has completed its work.  An invariant is a condition on some
class or type that must remain true throughout the life of instances of that
class or type.

Assertions on methods (in object-oriented programming languages) take advantage
of the fact that data and methods are bound to each other.   In particular,
Eiffel
does this very well.  Java was not originally designed for assertions so there
are
some inconsistencies that one does not find in Eiffel.   It is my understanding
that
standard PL/I is not object-oriented, but I'm not certain whether this is an
issue.
PL/I, as I understand it, does not support full inheritance except in a
non-standard
version mentioned in an earlier contribution to this forum.

There might be a concern about the scope of an assertion in a procedural
language such as PL/I.   In Eiffel, the assertion is within the scope of the
class within which it is defined.   Further, it will apply to classes that are
derived from the class in which it is declared.   That is, it is inherited.

In any case, I will look at the PL/I documentation again to see how this
mechanism actually works, and try to determine whether it does, in fact,
correspond to the notion of pre-, post-, and invariant conditions.

Thanks for your comments,

Richard Riehle




0
adaworks2 (748)
12/29/2005 4:59:44 AM
"robin" <robin_v@bigpond.com> wrote in message
news:HXEsf.124027$V7.71765@news-server.bigpond.net.au...
>
> <adaworks@sbcglobal.net> wrote in message
>
> PL/I is not Eiffel.
>
Most certainly, it is not.   Eiffel is a more modern object-oriented language
designed by one of the most gifted programming language designers of our
time.  He has learned from the shortcomings of previous language designs.
Even as good a design as it is, Eiffel does have design features that are not
ideal under all circumstances.
>
> Assertions can be implemented trivially in PL/I via the preprocessor.
>
I am always wary of any notion that some programming construct can be
"implemented trivially."  I have been programming for well over forty years
in a variety of languages, and even the simple programming problems often
introduce less than trivial concerns.

Even in languages that support a good model of assertions, not all is trivial.
It is quite easy to create an assertion that is self-contradictory.  It is easy
to
create a pre-condition that makes no sense given the post-condition, or vice
versa.   It is very easy to declare an invariant that consistently raises
surprising
exceptions.

Pre-processors seldom include any kind of theorem-provers, logic checking,
or other protections against unwisely declared assertions.  Even really good
assertion-based languages can miss such things.  So, I would be surprised
if the PL/I pre-processor is so intelligent that it can evaluate an assertion
in terms of the corresponding source code, before the compiler has even
done its work.   Then again, you know PL/I much better than I, so you
might be right.   Allow me to be skeptical, or show me how this
could possibly work.
>
> > It is no sin to admit the shortcomings of one's favorite language.  Every
> > language has its shortcomings and failure to acknowledge them borders on
zealotry
> > rather  than reason.
>
> You have described yourself.
>
Perhaps.  I would hope it does not describe you.   Ada has it shortcomings.
Eiffel has its shortcomings.  C++ has an abundance of shortcomings where each
new version seems intended to fix some problem with previous versions.  I cannot
think of a language that does not have shortcomings.  I wonder if you are of the
belief that PL/I has none.  If so, you might want to ask yourself about whether
you have placed zealotry above reason.

I am asking questions here to get a better understanding of PL/I.  Tom Linden, a
person I respect, is replying with well-reasoned answers.  He and I have not
resorted to insults.   I welcome your technical contribution, when you
have one to make.   Otherwise, I would ask you to exercise restraint when you
are simply inspired to rant.

Thanks.

Richard Riehle


0
adaworks2 (748)
12/29/2005 5:25:11 AM
"Tom Linden" <tom@kednos.com> wrote in message
news:ops2ivctcgzgicya@hyrrokkin...
> On Wed, 28 Dec 2005 08:21:41 GMT, <adaworks@sbcglobal.net> wrote:
>
> > I do not doubt that it is more powerful than C's preprocessor.  My doubts
> > have to do with the ability to get the full effect of pre-conditions,
> > post-conditions,
> > and invariants using preprocessor directives and macros.
>
> OK, I know now what you are after, I had a look at
> http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
>
I just looked more closely at the web site you provided.  Java, as described
in this web page, falls far short of a good model for design with assertions.

Richard


0
adaworks2 (748)
12/29/2005 5:28:02 AM
<adaworks@sbcglobal.net> wrote in message
news:8U%qf.34889$BZ5.8794@newssvr13.news.prodigy.com...
>
> "robin" <robin_v@bigpond.com> wrote in message
> news:0dLpf.61827$V7.36800@news-server.bigpond.net.au...
> > <adaworks@sbcglobal.net> wrote in message
> > >
> > > A programming language must be internally consistent at every point in
> > > its design and be free of surprise in its usage.   It should be free of
> > > constructs  that cannot be checked by a well-written compiler.   A
developer should
> > > not be required to learn all of the language when the problems to be
solved
> > > require only a knowledge of some of the language.
> > >
> > > The language modules need to support high cohesion, low coupling.   We
should
> > > be able to use the same language for our scientific and engineering
problems
> > > and our business data processing problems.   We should be able to tailor
that
> > > language to many different kinds of applications.
> >
> > Sounds like PL/I.
> >
> Perhaps.  I was thinking of Ada.

Certainly PL/I, because that is precisely what PL/I was designed
to do (and did) when it was released in 1966, namely,
to be at home with scientific and business applications.


0
robin_v (2737)
12/29/2005 6:04:48 AM
On Thu, 29 Dec 2005 04:59:44 GMT, <adaworks@sbcglobal.net> wrote:

>
> "Tom Linden" <tom@kednos.com> wrote in message
> news:ops2ivctcgzgicya@hyrrokkin...
>>
>> OK, I know now what you are after, I had a look at
>> http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
>>
>> In my view what they have done is to reinvent the signalling
>> mechanism of PL/I, which is, in fact, more powerful.  Some assertions,
>> e.g., range and bounds can be implicitly accomplished in PL/I; whereas,
>> in languages with lower level of abstraction like C or Java in this case
>> they must be made explicit.  Remember in PL/I, CONDITION (which is a
>> generalized form for assertion) is a data type, and well written PL/I
>> code should abound with ON-Conditions both predefined and user defined,
>> thereby leading to the possibility of writing fault tolerant, and
>> possibly self correcting code.
>
> I don't remember much about the signalling mechanism in PL/I.  I do  
> recall
> CONDITION, but when I programmed in PL/I I was not using it except
> in very elementary forms, mostly the predefined forms.
>
> At the method level, a pre-condition is a boolean statement that must be
> true before the called method (procedure/function) will be successful.  A
> post-condition is a boolean statement describing what must be true when
> the method has completed its work.  An invariant is a condition on some
> class or type that must remain true throughout the life of instances of  
> that
> class or type.

Well, ISTM that assertions are simply if statements by another name.
>
> Assertions on methods (in object-oriented programming languages) take  
> advantage
> of the fact that data and methods are bound to each other.   In  
> particular,
> Eiffel
> does this very well.  Java was not originally designed for assertions so  
> there
> are
> some inconsistencies that one does not find in Eiffel.   It is my  
> understanding
> that
> standard PL/I is not object-oriented, but I'm not certain whether this  
> is an
> issue.
> PL/I, as I understand it, does not support full inheritance except in a
> non-standard
> version mentioned in an earlier contribution to this forum.

PL/I is scope and has therefor lexical inheritance and when a conditon is  
signalled
(read assertion if you like) in any scope, stacks are unwound until a  
matching
handler is found.  Upon completion of the handler control returns to the  
instruction
following the one that caused the signal.
>
> There might be a concern about the scope of an assertion in a procedural
> language such as PL/I.   In Eiffel, the assertion is within the scope of  
> the
> class within which it is defined.   Further, it will apply to classes  
> that are
> derived from the class in which it is declared.   That is, it is  
> inherited.
>
> In any case, I will look at the PL/I documentation again to see how this
> mechanism actually works, and try to determine whether it does, in fact,
> correspond to the notion of pre-, post-, and invariant conditions.
>
> Thanks for your comments,
>
> Richard Riehle
>
>
>
>

0
tom284 (1839)
12/29/2005 2:35:43 PM
Tom Linden wrote:
> PL/I is scope and has therefor lexical inheritance and when a conditon 
> is signalled
> (read assertion if you like) in any scope, stacks are unwound until a 
> matching
> handler is found.  Upon completion of the handler control returns to the 
> instruction
> following the one that caused the signal.

That is misleading. The context is unwound dynamically to the context in 
which the appropriate ON statement was /executed/. Lexical scope has 
nothing to do with it. Except among the PL/I-can-do-no-wrong crowd, this 
is generally regarded as having been a hideous mistake, an incorrect 
generalization to a dynamic and scoped environment of such functions as 
SPIE and STAE in the flat, static, assembler-language environment of the 
OS/360 operating system.

And control does not return following the ERROR condition; the program 
is terminated, unless the ERROR unit is exited via a GOTO.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
12/29/2005 10:10:32 PM
"Tom Linden" <tom@kednos.com> wrote in message
news:ops2ivctcgzgicya@hyrrokkin...
> On Wed, 28 Dec 2005 08:21:41 GMT, <adaworks@sbcglobal.net> wrote:
>
> > I do not doubt that it is more powerful than C's preprocessor.  My doubts
> > have to do with the ability to get the full effect of pre-conditions,
> > post-conditions,
> > and invariants using preprocessor directives and macros.
>
> OK, I know now what you are after, I had a look at
> http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
>
> In my view what they have done is to reinvent the signalling
> mechanism of PL/I, which is, in fact, more powerful.  Some assertions,
> e.g., range and bounds can be implicitly accomplished in PL/I; whereas,
> in languages with lower level of abstraction like C or Java in this case
> they must be made explicit.  Remember in PL/I, CONDITION (which is a
> generalized form for assertion) is a data type, and well written PL/I
> code should abound with ON-Conditions both predefined and user defined,
> thereby leading to the possibility of writing fault tolerant, and
> possibly self correcting code.

Not to forget that SIZE and FIXEDOVERFLOW exist for a similar
purpose.  Especially in the case of FIXED BINARY, which permits
variables to be declared with precisions ranging from 1 to the maximum
available (1 .. 63 typically at least 31, signed to 32 and up to 64).
These provide an automatic protection on assignment.

>  Of course, very few programmers lack
> the mental capacity or the drive to think about contingency or
> fault-tree analysis, which is readily amenable to algebraic methods
> and probablistic models, which is somthing we were taught (on the job)
> 40 years ago before the invention of Computer Science curricula, the
> latter. of which, seem to be preoccupied with creating nomenclature,
> reminiscent of Spengler's concept of civilization.

Unfortunately it seems that contingencies are not routinely considered.
The lack of subscript, string, and overflow checks is evidence of this.
(This is not something pertaining just to PL/I [for which there is
little excuse for not using them] but to most langages - even C,
where errors from function calls are routinely ignored.)
    In the case of the Airbus730 (?) -- recently documented on TV --
no consideration was given to the possibility of a fuel leak;
consequently the plane lost 17 tons of fuel in some 30 minutes
through a broken fuel pipe, without warning from the on-board
computers before one engine had "consumed" all the fuel in its tank.
The passengers were lucky to have a skilled pilot who managed
glide the plane a phenomenal distance to a mid-ocean airfield.
    In another airplane incident, no-one condidered the possibility
that the air pressure vent to the outside world might become
covered up (as it routinely is during exterior cleaning of the
fuselage).  Consequently, the altimeters went haywire as soon as the craft
became airborne (because the operator forgot to remove the tape
covering the vent[s] when the cleaning was finished).  And the
crew thought that all the problems were caused by a faulty computer.
The computer software did not take this human error into account.
The passengers were not so lucky in this instance.

> I had somwhere a paper called something like "On the PL/I Signalling
> Mechanism" Don't recall the author, but i think it was in Sigplan, maybe
> late 60's,  Peter probably has a copy.

This is still available.  Search Google for PL/I EXCEPTION.
And yes, IIRC, it was SIGPLAN Notices.

> Tom


0
robin_v (2737)
12/29/2005 10:29:55 PM
Tom Linden wrote:
> On Wed, 28 Dec 2005 08:21:41 GMT, <adaworks@sbcglobal.net> wrote:
> 
>> I do not doubt that it is more powerful than C's preprocessor.  My doubts
>> have to do with the ability to get the full effect of pre-conditions,
>> post-conditions,
>> and invariants using preprocessor directives and macros.
> 
> 
> OK, I know now what you are after, I had a look at
> http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
> 
> In my view what they have done is to reinvent the signalling
> mechanism of PL/I, which is, in fact, more powerful.  

That was my thought when I read the citation.  I thought I had to have 
missed something.

> 
> I had somwhere a paper called something like "On the PL/I Signalling
> Mechanism" Don't recall the author, but i think it was in Sigplan, maybe
> late 60's,  Peter probably has a copy.

Maybe "Exception handling in PL/I" by M Donald McClaren (1977)?
http://doi.acm.org/10.1145/800022.808316

I may have it in hardcopy, but not in PDF format.  Somehow it missed my 
bibliography.

0
Peter_Flass (956)
12/29/2005 11:09:33 PM
Peter Flass wrote:
> Tom Linden wrote:
>> On Wed, 28 Dec 2005 08:21:41 GMT, <adaworks@sbcglobal.net> wrote:
>>
>>> I do not doubt that it is more powerful than C's preprocessor.  My 
>>> doubts
>>> have to do with the ability to get the full effect of pre-conditions,
>>> post-conditions,
>>> and invariants using preprocessor directives and macros.
>>
>>
>> OK, I know now what you are after, I had a look at
>> http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
>>
>> In my view what they have done is to reinvent the signalling
>> mechanism of PL/I, which is, in fact, more powerful.  
> 
> That was my thought when I read the citation.  I thought I had to have 
> missed something.

Not really. Java 1.0 covered that with the "try {...} catch (...) {...}" 
and "throw ..." statements, derived, as far as syntax and gross 
semantics go, from C++ (though Java adds the interesting "finally {...}" 
option). The Java 1.4 assertion facility merely blends that with a 
simple assertion mechanism borrowed from C, except that Java's 
assertions are toggled at runtime, rather than at compile time.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
12/30/2005 1:28:08 AM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:w9Zsf.9417$L75.2058@fe12.lga...
> Tom Linden wrote:
> > PL/I is scope and has therefor lexical inheritance and when a conditon
> > is signalled
> > (read assertion if you like) in any scope, stacks are unwound until a
> > matching
> > handler is found.  Upon completion of the handler control returns to the
> > instruction
> > following the one that caused the signal.
>
> That is misleading. The context is unwound dynamically to the context in
> which the appropriate ON statement was /executed/. Lexical scope has
> nothing to do with it.
> And control does not return following the ERROR condition; the program
> is terminated, unless the ERROR unit is exited via a GOTO.

Tom wasn't talking about the ERROR condition.  He was talking
about user-defined conditions, and he is correct.
Control returns to the instruction following the one that signalled the
condition, viz., the SIGNAL statement.  Tom is correct.




0
robin_v (2737)
12/30/2005 4:50:52 AM
<adaworks@sbcglobal.net> wrote in message
news:XqKsf.39991$BZ5.32983@newssvr13.news.prodigy.com...
>
> "robin" <robin_v@bigpond.com> wrote in message
> news:HXEsf.124027$V7.71765@news-server.bigpond.net.au...
> >
> > <adaworks@sbcglobal.net> wrote in message
> >
> > PL/I is not Eiffel.
> >
> Most certainly, it is not.   Eiffel is a more modern object-oriented language
> designed by one of the most gifted programming language designers of our
> time.  He has learned from the shortcomings of previous language designs.
> Even as good a design as it is, Eiffel does have design features that are not
> ideal under all circumstances.
> >
> > Assertions can be implemented trivially in PL/I via the preprocessor.
> >
> I am always wary of any notion that some programming construct can be
> "implemented trivially."  I have been programming for well over forty years
> in a variety of languages, and even the simple programming problems often
> introduce less than trivial concerns.
>
> Even in languages that support a good model of assertions, not all is trivial.
> It is quite easy to create an assertion that is self-contradictory.  It is
easy to
> create a pre-condition that makes no sense given the post-condition, or vice
> versa.   It is very easy to declare an invariant that consistently raises
surprising
> exceptions.
>
> Pre-processors seldom include any kind of theorem-provers, logic checking,
> or other protections against unwisely declared assertions.  Even really good
> assertion-based languages can miss such things.  So, I would be surprised
> if the PL/I pre-processor is so intelligent that it can evaluate an assertion
> in terms of the corresponding source code, before the compiler has even
> done its work.   Then again, you know PL/I much better than I, so you
> might be right.   Allow me to be skeptical, or show me how this
> could possibly work.
> >
> > > It is no sin to admit the shortcomings of one's favorite language.  Every
> > > language has its shortcomings and failure to acknowledge them borders on
> > > zealotry rather  than reason.
> >
> > You have described yourself.
> >
> Perhaps.  I would hope it does not describe you.   Ada has it shortcomings.
> Eiffel has its shortcomings.  C++ has an abundance of shortcomings where each
> new version seems intended to fix some problem with previous versions.  I
cannot
> think of a language that does not have shortcomings.  I wonder if you are of
the
> belief that PL/I has none.  If so, you might want to ask yourself about
whether
> you have placed zealotry above reason.

You're repeating yourself.  And describing yourself.

> I am asking questions here to get a better understanding of PL/I.  Tom Linden,
a
> person I respect, is replying with well-reasoned answers.  He and I have not
> resorted to insults.   I welcome your technical contribution, when you
> have one to make.   Otherwise, I would ask you to exercise restraint when you
> are simply inspired to rant.

Can what you have wirtten in this post be described as "rant"?


0
robin_v (2737)
12/31/2005 7:39:06 AM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:w9Zsf.9417$L75.2058@fe12.lga...
> Tom Linden wrote:
> > PL/I is scope and has therefor lexical inheritance and when a conditon
> > is signalled
> > (read assertion if you like) in any scope, stacks are unwound until a
> > matching
> > handler is found.  Upon completion of the handler control returns to the
> > instruction
> > following the one that caused the signal.
>
> That is misleading. The context is unwound dynamically to the context in
> which the appropriate ON statement was /executed/. Lexical scope has
> nothing to do with it. Except among the PL/I-can-do-no-wrong crowd, this
> is generally regarded as having been a hideous mistake, an incorrect
> generalization to a dynamic and scoped environment of such functions as
> SPIE and STAE in the flat, static, assembler-language environment of the
> OS/360 operating system.

By that logic, anything that isn't trivially simple to implement should not
be in a language.  For example, recursion should never have been included
because it needed a hardware stack, which the S/360 didn't have.
The S/360 had nothing of the hardware that, say, the Burrought 5000
series had that supported stacks and addressing.  We should do away
with data structures, conversions to and from floating-point during I/O, etc.,
because these are features that are not trivial to implement.  Best to get
rid of data-directed I/O for the same reason.  And generic functions.
But these features were included <b>because people needed them,</b>
including conditions.  <b>Yet the language was implemented,
including condition handling, as envisaged by the designers.</b>

    However, software is designed to make things easier for the programmer,
rather than to make him do all the work [the latter being the
design philosophy of Pascal, wrt strings, exponentiation, etc.].

    In the case of condition handling in PL/I, the stack (whether hardware
or software) gives access to dynamic variables (i.e., stack frame via pointers);
static variables are always accessible, again via a pointer.

    When mixing compiled code from different languages,
PL/I is able to trap and to handle interrupts generated in compiled code
from other languages -- something that would not be possible with
the interrupt handling that you promote.  In PL/I, when a condition
is handled by the calling procedure [when the interrupt occurs
in compiled code from language X], it obviously cannot say
much about the variables in Language X's code.  However,
trap it did, and could issue an error message, and even recover
[continue] from that error.



0
robin_v (2737)
12/31/2005 7:39:10 AM
Peter Flass <Peter_Flass@Yahoo.com> writes:
> Tom Linden wrote:

> > I had somwhere a paper called something like "On the PL/I Signalling
> > Mechanism" Don't recall the author, but i think it was in Sigplan, maybe
> > late 60's,  Peter probably has a copy.
> 
> Maybe "Exception handling in PL/I" by M Donald McClaren (1977)?
> http://doi.acm.org/10.1145/800022.808316
> 
> I may have it in hardcopy, but not in PDF format.  Somehow it missed my 
> bibliography.

Speaking of Don McClaren, does anyone know his whereabouts?
The Multics alumni site doesn't have any info.
0
mojaveg595 (241)
12/31/2005 1:28:38 PM
"robin" <robin_v@bigpond.com> wrote in message
news:uAqtf.147381$V7.484@news-server.bigpond.net.au...
>
> Can what you have wirtten in this post be described as "rant"?
>
This is my last communication with you.   It is clear you have no respect
for anything I might say and that makes conversation between us useless.

Richard Riehle


0
adaworks2 (748)
12/31/2005 2:14:31 PM
adaworks@sbcglobal.net wrote:
> "robin" <robin_v@bigpond.com> wrote in message
> news:uAqtf.147381$V7.484@news-server.bigpond.net.au...
>> Can what you have wirtten in this post be described as "rant"?
>>
> This is my last communication with you.   It is clear you have no respect
> for anything I might say and that makes conversation between us useless.

I'm afraid Robin is a fanatic. The truth? PL/I was a /huge/ leap forward 
among languages compilable to reasonably efficient object code in the 
mid-60's, and, with a few improvements, would still be viable today (OO 
and a concrete distinction between boolean and short-circuit operators, 
at present left to the vagaries of the compiler's optimizing pass, would 
be a start). Nearly all my professional programming on S/360-type 
mainframes was in PL/I or assembler, and I shudder to think what would 
have happened to my output, had I been forced to use FORTRAN and COBOL 
instead.

But PL/I is no longer a serious rival to Ada, its closest parallel. It 
has had few significant upgrades since it was first introduced 40 years 
ago, and it not likely to seriously upgraded now.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/1/2006 2:59:44 AM
robin wrote:
> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> news:w9Zsf.9417$L75.2058@fe12.lga...
>> Tom Linden wrote:
>>> PL/I is scope and has therefor lexical inheritance and when a conditon
>>> is signalled
>>> (read assertion if you like) in any scope, stacks are unwound until a
>>> matching
>>> handler is found.  Upon completion of the handler control returns to the
>>> instruction
>>> following the one that caused the signal.
>> That is misleading. The context is unwound dynamically to the context in
>> which the appropriate ON statement was /executed/. Lexical scope has
>> nothing to do with it. Except among the PL/I-can-do-no-wrong crowd, this
>> is generally regarded as having been a hideous mistake, an incorrect
>> generalization to a dynamic and scoped environment of such functions as
>> SPIE and STAE in the flat, static, assembler-language environment of the
>> OS/360 operating system.
> 
> By that logic, anything that isn't trivially simple to implement should not
> be in a language.

The problem is not that the PL/I ON model is hard to implement, but that 
it has unnecessarily complex and unpredictable semantics. Many, many 
languages since PL/I have implemented exception handlers. All of them 
have looked at the PL/I ON-statement in horror (this is frequently 
expressly stated in rationale documents) and gone with the model used 
(grossly) by Ada, C++, Java, Ruby, etc., etc., instead. The designers of 
PL/I looked as assembler, and drew the obvious, but wrong conclusion, 
"Exception handlers are enabled by executable statements." C, to the 
extent that it can be said to have exception handlers, did the same, but 
at least defined them with GOTO logic, mimicking the underlying 
operating-system constructs.

Another PL/I idea universally rejected has been the notion of using 
exception handlers to deal with expected conditions. Its utility for 
certain cases of ENDPAGE is undeniable, but there are real-world 
circumstances that ENDPAGE fails to serve, and the ENDPAGE semantics 
nevertheless complicate. The use of exception handlers to handle 
expected end-of-input, on the other hand, is universally eschewed (which 
is why the ENDFILE() function has been belatedly added).

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/1/2006 3:10:07 AM
On Sat, 31 Dec 2005 21:59:44 -0500, John W. Kennedy  
<jwkenne@attglobal.net> wrote:

> adaworks@sbcglobal.net wrote:
>> "robin" <robin_v@bigpond.com> wrote in message
>> news:uAqtf.147381$V7.484@news-server.bigpond.net.au...
>>> Can what you have wirtten in this post be described as "rant"?
>>>
>> This is my last communication with you.   It is clear you have no  
>> respect
>> for anything I might say and that makes conversation between us useless.
>
> I'm afraid Robin is a fanatic. The truth? PL/I was a /huge/ leap forward  
> among languages compilable to reasonably efficient object code in the  
> mid-60's, and, with a few improvements, would still be viable today (OO  
> and a concrete distinction between boolean and short-circuit operators,  
> at present left to the vagaries of the compiler's optimizing pass, would  
> be a start).

Could you explain what you mean by that?

Nearly all my professional programming on S/360-type
> mainframes was in PL/I or assembler, and I shudder to think what would  
> have happened to my output, had I been forced to use FORTRAN and COBOL  
> instead.
>
> But PL/I is no longer a serious rival to Ada, its closest parallel. It  
> has had few significant upgrades since it was first introduced 40 years  
> ago, and it not likely to seriously upgraded now.

Not sure what you mean by that statement, is that a technical analysis?
Ada is a dead language from a market acceptance point of view.  You might
claim the same for PL/I; however, I would venture to guess that the number
of lines of code of PL/I to Ada in production is likely 100000:1 if not
more.

In the past almost 40 years, I have coded in may languages and have written
or worked on compilers for maybe a dozen languages, granted none of the  
newer
fashion.  I don't seem an advancement in the state of the art in languages.
Indeed, consider Fortran and C, for example,  that which has been added  
could
have been lifted from the PL/I definition.  Interestingly,  you previously
�ommented on lexical scoping as a mistake, yet GNU C has added that some  
years
ago.

I am not fond of the manner in which IBM has extended the language, because
it lacks rigor and is rather ad hoc, and all the options required to run  
the
compiler, is frankly embarassing, and adds little or nothing to the  
language.
0
tom284 (1839)
1/1/2006 4:10:29 AM
On Sat, 31 Dec 2005 22:10:07 -0500, John W. Kennedy  
<jwkenne@attglobal.net> wrote:

> robin wrote:
>> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
>> news:w9Zsf.9417$L75.2058@fe12.lga...
>>> Tom Linden wrote:
>>>> PL/I is scope and has therefor lexical inheritance and when a conditon
>>>> is signalled
>>>> (read assertion if you like) in any scope, stacks are unwound until a
>>>> matching
>>>> handler is found.  Upon completion of the handler control returns to  
>>>> the
>>>> instruction
>>>> following the one that caused the signal.
>>> That is misleading. The context is unwound dynamically to the context  
>>> in
>>> which the appropriate ON statement was /executed/. Lexical scope has
>>> nothing to do with it. Except among the PL/I-can-do-no-wrong crowd,  
>>> this
>>> is generally regarded as having been a hideous mistake, an incorrect
>>> generalization to a dynamic and scoped environment of such functions as
>>> SPIE and STAE in the flat, static, assembler-language environment of  
>>> the
>>> OS/360 operating system.
>>  By that logic, anything that isn't trivially simple to implement  
>> should not
>> be in a language.
>
> The problem is not that the PL/I ON model is hard to implement, but that  
> it has unnecessarily complex and unpredictable semantics. Many, many  
> languages since PL/I have implemented exception handlers. All of them  
> have looked at the PL/I ON-statement in horror (this is frequently  
> expressly stated in rationale documents) and gone with the model used  
> (grossly) by Ada, C++, Java, Ruby, etc., etc., instead. The designers of  
> PL/I looked as assembler, and drew the obvious, but wrong conclusion,  
> "Exception handlers are enabled by executable statements." C, to the  
> extent that it can be said to have exception handlers, did the same, but  
> at least defined them with GOTO logic, mimicking the underlying  
> operating-system constructs.

Setjmp and longjmp are primitive copies of the PL/I signalling mechanisms
and lack semantic analysis.

John,  I really don't understand what you are saying.  PL/I condition
handling is not at all complex.  In fact it is a simple as you can make it
and still provide the power that it does.  Moreover, there is nothing
unpredictable with the semantics, that i am aware of.  Could you please
provide an example to amplify your assertion?
>
> Another PL/I idea universally rejected has been the notion of using  
> exception handlers to deal with expected conditions. Its utility for  
> certain cases of ENDPAGE is undeniable, but there are real-world  
> circumstances that ENDPAGE fails to serve, and the ENDPAGE semantics  
> nevertheless complicate. The use of exception handlers to handle  
> expected end-of-input, on the other hand, is universally eschewed (which  
> is why the ENDFILE() function has been belatedly added).
>
Unexpected conditions, what does that really mean?  Well, if I venture a  
guess
it would have to be, we got an error but we don't what it is.  This happens
in any language, so is a degenerate case, derived from poor programming  
practice
and not worthy of further consideration in the current context.  PL/I  
provides a set
of standard signals, of which you have mention several, and these are  
mundane
for purposes of this discussion.  it is the user generated signals that are
important for writing fault tolerant code, and that can only be done by  
those
initmate with the application.  Properly employed, signals provide  
precisely the
assertion mechanisms that Richard questioned earlier in this thread

0
tom284 (1839)
1/1/2006 4:28:36 AM
John W. Kennedy wrote:
 > The designers of
> PL/I looked as assembler, and drew the obvious, but wrong conclusion, 
> "Exception handlers are enabled by executable statements." C, to the 
> extent that it can be said to have exception handlers, did the same, but 
> at least defined them with GOTO logic, mimicking the underlying 
> operating-system constructs.

You have said this before, and I have been considxering your thoughts 
before adding my $.02 (d@mn PeeCee keyboards don't have a "cent" sign.)

As usual with PL/I, its design provides the most flexibility.  It is 
entirely possible to mimic the exception-handling constructs of other 
languages in PL/I, but not (AIUI) the reverse.  If you want Java's (and 
C++'s?) 'try/catch', or if you want lexical rather than dynamic scoping, 
then just code the ON-statement before the statement or block being 
checked, and the corresponding REVERT afterwards. If you want C's model, 
just code a GOTO as the ON-Unit.  If you like the assembler model, as I 
do, then stick with the dynamic model, which provides, I would say. 
"defense in depth" with the innermost ON-Unit providing the most 
specific recovery possibilities, and successively outer ones more 
general recovery, of the nature of "terminate thread and exit."

As I've mentioned before, having executable rather than declarative 
ON-Statements allows the possibility of selecting alternative error 
handing logic at run-time, rather than having to re-compile the program 
to change the action.  Therefore the standard action might be just print 
a message and terminate.  A run-time switch would allow the programmer 
to execute an "ON ERROR PUT DATA" statement, or other debugging tools.

> 
> Another PL/I idea universally rejected has been the notion of using 
> exception handlers to deal with expected conditions. Its utility for 
> certain cases of ENDPAGE is undeniable, but there are real-world 
> circumstances that ENDPAGE fails to serve, and the ENDPAGE semantics 
> nevertheless complicate. The use of exception handlers to handle 
> expected end-of-input, on the other hand, is universally eschewed (which 
> is why the ENDFILE() function has been belatedly added).
> 

We are in agreement here.  This was a mistake, although not a major one. 
  I usually code "ON ENDFILE(x) EOF_x = '1'b;", and then say "READ 
FILE(x)...; IF EOF_x THEN...".

0
Peter_Flass (956)
1/1/2006 1:51:13 PM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:mKHtf.12751$L75.656@fe12.lga...
> robin wrote:
> > "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> > news:w9Zsf.9417$L75.2058@fe12.lga...
> >> Tom Linden wrote:
> >>> PL/I is scope and has therefor lexical inheritance and when a conditon
> >>> is signalled
> >>> (read assertion if you like) in any scope, stacks are unwound until a
> >>> matching
> >>> handler is found.  Upon completion of the handler control returns to the
> >>> instruction
> >>> following the one that caused the signal.
> >> That is misleading. The context is unwound dynamically to the context in
> >> which the appropriate ON statement was /executed/. Lexical scope has
> >> nothing to do with it. Except among the PL/I-can-do-no-wrong crowd, this
> >> is generally regarded as having been a hideous mistake, an incorrect
> >> generalization to a dynamic and scoped environment of such functions as
> >> SPIE and STAE in the flat, static, assembler-language environment of the
> >> OS/360 operating system.
> >
> > By that logic, anything that isn't trivially simple to implement should not
> > be in a language.
>
> The problem is not that the PL/I ON model is hard to implement, but that
> it has unnecessarily complex and unpredictable semantics.

Au contraire, the semantics are entirely predictable.

> Many, many
> languages since PL/I have implemented exception handlers. All of them
> have looked at the PL/I ON-statement in horror (this is frequently
> expressly stated in rationale documents) and gone with the model used
> (grossly) by Ada, C++, Java, Ruby, etc., etc., instead. The designers of
> PL/I looked as assembler, and drew the obvious, but wrong conclusion,
> "Exception handlers are enabled by executable statements." C, to the
> extent that it can be said to have exception handlers, did the same, but
> at least defined them with GOTO logic, mimicking the underlying
> operating-system constructs.
>
> Another PL/I idea universally rejected has been the notion of using
> exception handlers to deal with expected conditions. Its utility for
> certain cases of ENDPAGE is undeniable, but there are real-world
> circumstances that ENDPAGE fails to serve, and the ENDPAGE semantics
> nevertheless complicate. The use of exception handlers to handle
> expected end-of-input, on the other hand, is universally eschewed

Frayed knot.  They are typically used.

> (which is why the ENDFILE() function has been belatedly added).

Some prefer the ENDFILE function.  Let them use it if they want.


0
robin_v (2737)
1/1/2006 1:58:01 PM
<adaworks@sbcglobal.net> wrote in message
news:bnwtf.60064$tV6.45101@newssvr27.news.prodigy.net...
>
> "robin" <robin_v@bigpond.com> wrote in message
> news:uAqtf.147381$V7.484@news-server.bigpond.net.au...
> >
> > Can what you have wirtten in this post be described as "rant"?
> >
> This is my last communication with you.   It is clear you have no respect
> for anything I might say and that makes conversation between us useless.

I'd expect that from you following your two postings of
insulting remarks - the second repeating the first lot,
and you persisted, even after my pointing out that your remarks
were insulting - and put-downs.

Can you have forgotten already that in your previous two postings,
you freely used the words "rant", "zealotry", and a host of other phrases
of similar intent.

Have a good day.


0
robin_v (2737)
1/1/2006 1:58:02 PM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:DAHtf.12721$L75.4472@fe12.lga...
> adaworks@sbcglobal.net wrote:
> > "robin" <robin_v@bigpond.com> wrote in message
> > news:uAqtf.147381$V7.484@news-server.bigpond.net.au...
> >> Can what you have wirtten in this post be described as "rant"?
> >>
> > This is my last communication with you.   It is clear you have no respect
> > for anything I might say and that makes conversation between us useless.
>
> I'm afraid Robin is a fanatic.

Only to an Ada fanatic.

> The truth? PL/I was a /huge/ leap forward
> among languages compilable to reasonably efficient object code in the
> mid-60's, and, with a few improvements, would still be viable today (OO
> and a concrete distinction between boolean and short-circuit operators,

I can live without short-circuit operators and I have done OO in PL/I.
There are other things that need to be improved first.

> at present left to the vagaries of the compiler's optimizing pass, would
> be a start). Nearly all my professional programming on S/360-type
> mainframes was in PL/I or assembler, and I shudder to think what would
> have happened to my output, had I been forced to use FORTRAN and COBOL
> instead.
>
> But PL/I is no longer a serious rival to Ada, its closest parallel. It
> has had few significant upgrades since it was first introduced 40 years
> ago,

That was because it was so far advanced when it was introduced.
It didn't need anything much done to it.
    But on a small point, list processing that was implemented was not
the model that was originally in the manuals.  When it was implemented
(after the first release of the compiler), it had significantly changed, IIRC.

>and it not likely to seriously upgraded now.

Again, for the same reason as above.
    You need to keep advances in perspective.
Fortran, you might recall, had dynamic storage allocation
only from 1991.  It still did not have error handling.  Nor in the
1995 update.


0
robin_v (2737)
1/1/2006 1:58:03 PM
Tom Linden wrote:

> On Sat, 31 Dec 2005 21:59:44 -0500, John W. Kennedy  
> <jwkenne@attglobal.net> wrote:
> 
>> adaworks@sbcglobal.net wrote:
>>
>>> "robin" <robin_v@bigpond.com> wrote in message
>>> news:uAqtf.147381$V7.484@news-server.bigpond.net.au...
>>>
>>>> Can what you have wirtten in this post be described as "rant"?
>>>>
>>> This is my last communication with you.   It is clear you have no  
>>> respect
>>> for anything I might say and that makes conversation between us useless.
>>
>>
>> I'm afraid Robin is a fanatic. The truth? PL/I was a /huge/ leap 
>> forward  among languages compilable to reasonably efficient object 
>> code in the  mid-60's, and, with a few improvements, would still be 
>> viable today (OO  and a concrete distinction between boolean and 
>> short-circuit operators,  at present left to the vagaries of the 
>> compiler's optimizing pass, would  be a start).
> 
> 
> Could you explain what you mean by that?

This *is* a potential problem.  The incorrect, but nearly universal, 
usage is something like: "IF p^=NULL & p->whatever=...", which obviously 
depends on the IF-statement evaluation being short-circuited before 
evaluating the second condition if p is NULL.  [for the record, I now 
try to avoid this by saying "IF p^=NULL THEN IF...".  The boolean 
version of this is "b = (p^=NULL) & (p->whatever)...  I have put in 
logic to short-circuit the evaluation in the first case, but not in the 
second.  Without checking, I'd have to believe offhand that the standard 
is no short-circuiting in all cases.  This should be defined explicitly, 
even if only in the terms above.

>>
>> But PL/I is no longer a serious rival to Ada, its closest parallel. 
>> It  has had few significant upgrades since it was first introduced 40 
>> years  ago, and it not likely to seriously upgraded now.
> 
> 
> Not sure what you mean by that statement, is that a technical analysis?
> Ada is a dead language from a market acceptance point of view.  You might
> claim the same for PL/I; however, I would venture to guess that the number
> of lines of code of PL/I to Ada in production is likely 100000:1 if not
> more.

 From limited knowledge I'd thing Ada is more of a niche language than 
PL/I, being largely (AFAIK) confined to defense and similar markets. 
PL/I has more breath (sp?) of use  but probably not much more depth.
I'd like to see this change in the future.  PL/I is superior to C 
(probably no argument here), and could surpass C++ with a few additions, 
as Peter's paper shows.  Now that hardware is no longer too limited to 
support PL/I effectively, I'd like to see it move in on C, due to its 
obvious superiority.

0
Peter_Flass (956)
1/1/2006 2:13:30 PM
On Sun, 01 Jan 2006 14:13:30 GMT, Peter Flass <Peter_Flass@Yahoo.com>  
wrote:

> This *is* a potential problem.  The incorrect, but nearly universal,  
> usage is something like: "IF p^=NULL & p-
>> whatever=...", which obviously depends on the IF-statement evaluation  
>> being short-circuited before evaluating the
> second condition if p is NULL.  [for the record, I now try to avoid this  
> by saying "IF p^=NULL THEN IF...".  The boolean
>  version of this is "b = (p^=NULL) & (p->whatever)...  I have put in  
> logic to short-circuit the evaluation in the first case, but not in the  
> second.  Without checking, I'd have to believe offhand that the standard  
> is no short-circuiting in all cases.  This should be defined explicitly,  
> even if only in the terms above.
>
We provide two operators, AND THEN   and OR ELSE

http://www.kednos.com/pli/docs/REFERENCE_MANUAL/6291pro_016.html#index_x_799
0
tom284 (1839)
1/1/2006 2:49:22 PM
Tom Linden wrote:
> On Sat, 31 Dec 2005 21:59:44 -0500, John W. Kennedy 
> <jwkenne@attglobal.net> wrote:
> 
>> adaworks@sbcglobal.net wrote:
>>> "robin" <robin_v@bigpond.com> wrote in message
>>> news:uAqtf.147381$V7.484@news-server.bigpond.net.au...
>>>> Can what you have wirtten in this post be described as "rant"?
>>>>
>>> This is my last communication with you.   It is clear you have no 
>>> respect
>>> for anything I might say and that makes conversation between us useless.
>>
>> I'm afraid Robin is a fanatic. The truth? PL/I was a /huge/ leap 
>> forward among languages compilable to reasonably efficient object code 
>> in the mid-60's, and, with a few improvements, would still be viable 
>> today (OO and a concrete distinction between boolean and short-circuit 
>> operators, at present left to the vagaries of the compiler's 
>> optimizing pass, would be a start).
> 
> Could you explain what you mean by that?

The language is in limbo as to whether the following will crash when x 
is zero:

   if x ^= 0 & y/x < 10 then ...

Some compilers, as a side-effect of optimization, will compile it as 
though it were C

   if (x != 0 && y/x < 10) ...

or Ada

   if x /= 0 and then y/x < 10 then ...

but the definition of the language actually implies C

   if (x != 0 & y/x < 10) ...

or Ada

   if x /= 0 and y/x < 10 then ...

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/1/2006 4:45:00 PM
robin wrote:
> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> news:DAHtf.12721$L75.4472@fe12.lga...
>> adaworks@sbcglobal.net wrote:
>>> "robin" <robin_v@bigpond.com> wrote in message
>>> news:uAqtf.147381$V7.484@news-server.bigpond.net.au...
>>>> Can what you have wirtten in this post be described as "rant"?
>>>>
>>> This is my last communication with you.   It is clear you have no respect
>>> for anything I might say and that makes conversation between us useless.
>> I'm afraid Robin is a fanatic.
> 
> Only to an Ada fanatic.

Will you, for God's sake, spend some time this year looking in a mirror? 
I spent /decades/ pushing PL/I, supporting PL/I, and coding in PL/I, and 
I'm still angry at the "If IBM created it, it must be evil," attitude 
that kept PL/I from becoming, in its time, the universal language for 
general programming. You'll find me quoted by name in a late-60's 
pro-PL/I IBM publication. I personally added 73-80 sequence checking, 
the column-1 convention, and the %INCLUDE statement to the PL/I (D) 
compiler for my site, and my employer once sent me as an ambassador to 
Hursley Labs to discuss language improvements.

But your repeated unreasoning assertions that every choice made by 
PL/I's designers forty years ago was wiser and better informed than the 
subsequent decisions of language designers with years of experience and 
hindsight are nothing but an embarrassment to those of us who still 
retain an affection for the old girl. You've become nothing but the 
mirror image of David Frank, trapped in a quasi-religious One True Way 
that has stunted your ability to think and learn.

PL/I made major mistakes. Run-time-set exception handling was a mistake. 
Confusing exception handling with expected-condition handling was a 
mistake. One-size-fits-all fixed-point precision rules were a mistake. 
Failure to distinguish between integer and generalized fixed-point 
arithmetic was a mistake. Anonymous pointers were a mistake. Failure to 
distinguish boolean from short-circuit logic operators was a mistake. 
The original PL/I tasking model was a mistake (which is why it was 
abandoned).

And in recent years, PL/I has fallen behind new developments. No OO 
facilities. No range checking. The old tasking model has been dropped, 
but the new one is at a stone-ax level. The verbose and unnecessary 
GENERIC attribute is still in use where modern languages have automatic 
overloading, and the macro language is an unnecessarily complex way to 
handle the problem dealt with in C++ by "templates" and in Ada by "generic".

> That was because it was so far advanced when it was introduced.
> It didn't need anything much done to it.

Ac ille respondens ait: tu dicis.

The world has moved on since 1965. Deal with it.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/1/2006 5:10:37 PM
Tom Linden wrote:
> Setjmp and longjmp are primitive copies of the PL/I signalling mechanisms
> and lack semantic analysis.

I doubt that PL/I had much to do with it. PL/I was the first HLL to 
implement exception handling -- but the concept already existed at the 
assembler-language level.

> John,  I really don't understand what you are saying.  PL/I condition
> handling is not at all complex.  In fact it is a simple as you can make it
> and still provide the power that it does.  Moreover, there is nothing
> unpredictable with the semantics, that i am aware of.  Could you please
> provide an example to amplify your assertion?

SAMPLE: PROCEDURE (X) RECURSIVE;
   DECLARE X FIXED BINARY;
   SELECT (X)
     WHEN (1)
       ON CONDITION (FOO)
         PUT SKIP DATA (X);
     WHEN (3)
       SIGNAL CONDITION (FOO);
     WHEN (5)
       RETURN;
     OTHERWISE;
   END;
   PUT SKIP DATA (X);
   CALL SAMPLE (X + 1);
END SAMPLE;

CALL SAMPLE (0);


> Unexpected conditions, what does that really mean?  Well, if I venture a 
> guess
> it would have to be, we got an error but we don't what it is.  This happens
> in any language, so is a degenerate case, derived from poor programming 
> practice
> and not worthy of further consideration in the current context.  PL/I 
> provides a set
> of standard signals, of which you have mention several, and these are 
> mundane
> for purposes of this discussion.  it is the user generated signals that are
> important for writing fault tolerant code, and that can only be done by 
> those
> initmate with the application.  Properly employed, signals provide 
> precisely the
> assertion mechanisms that Richard questioned earlier in this thread

The issue is that PL/I uses ON-conditions as the standard access to 
non-errors (most notably ENDFILE) that should instead be accessible by 
simple IF tests.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/1/2006 5:22:28 PM
On Sun, 01 Jan 2006 11:45:00 -0500, John W. Kennedy  
<jwkenne@attglobal.net> wrote:

> The language is in limbo as to whether the following will crash when x  
> is zero:
>    if x ^= 0 & y/x < 10 then ...
>
No limbo ther, it should crash.  The correct (safe) way to code this is

if x ^= 0 then if  y/x < 10 then

or with our compiler


if x ^= 0 &: y/x < 10 then
0
tom284 (1839)
1/1/2006 6:13:26 PM

Peter Flass wrote:
> Tom Linden wrote:
[snip]

>  From limited knowledge I'd thing Ada is more of a niche language than 
> PL/I, being largely (AFAIK) confined to defense and similar markets. 
> PL/I has more breath (sp?) of use  but probably not much more depth.
> I'd like to see this change in the future.  PL/I is superior to C 
> (probably no argument here), and could surpass C++ with a few additions, 
> as Peter's paper shows.  Now that hardware is no longer too limited to 
> support PL/I effectively, I'd like to see it move in on C, due to its 
> obvious superiority.

The biggest reason C took over was C compilers were free or low cost 
compared to PL/1.  Gcc is free and runs on just about everything.  I 
looked at buying a PL/1 compiler several times, but each time I was able 
to afford to pay more, the price went up just outside what I was willing 
to pay.  The first one I was able to afford was the IBM Personal which 
at that time was OS/2 only and I could not get OS/2 to load on my computer.
0
multicsfan (63)
1/1/2006 6:37:17 PM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:DAHtf.12721$L75.4472@fe12.lga...
> adaworks@sbcglobal.net wrote:
> > "robin" <robin_v@bigpond.com> wrote in message
> > news:uAqtf.147381$V7.484@news-server.bigpond.net.au...
> >> Can what you have wirtten in this post be described as "rant"?
> >>
> > This is my last communication with you.   It is clear you have no respect
> > for anything I might say and that makes conversation between us useless.
>
> I'm afraid Robin is a fanatic.

I have no interest in any comments or communication
that have to do with Robin.  He no longer exists for me.
>
> But PL/I is no longer a serious rival to Ada, its closest parallel. It
> has had few significant upgrades since it was first introduced 40 years
> ago, and it not likely to seriously upgraded now.
>
I began my inquiry, in this forum, because I wanted concrete information
that I could pass along to my students.   I teach a class at a graduate
school computer science program in comparative programming languages,
and my experience with PL/I is rather dated.

In that class I include functional languages such as Lisp, Scheme, Haskell,
and ML.  I also include a section on non-OOP imperative languages such
as Fortran, Pascal, C, older COBOL (it now has an OO capability) and even
smaller languages such as Forth.  Most of the class is devoted to
object-oriented
languages, or languages that provide good support for OOP.  We see languages
such as Smalltalk, C++, Ada, and Eiffel in this category, along with others.
Also,
the above list does not include all the topics in the class.

Because there are so many languages, I can only spend a small amount of time
on those of marginal interest.    I am not fond of C++, but I do have a couple
of weeks in the curriculum for it.

As to Ada, it continues to be used for military, space, and safety-critical
software.
There is also a growing use of it for transportation systems that require high
reliability, and for some systems that require strong security.    Eiffel,
another of
my favorites among OOP languages, has not caught on, but it is currently one of
the better designed languages.  I have not programmed any serious systems in
C#, so far, but I am finding that language to be interesting in some of its
capabilities.

My concern, with regard to PL/I, is whether it has continued to evolve in a way
that
it remains competitive, in features and capabilities, with newer languages.  It
is
apparent that I am going to have to experiment with it to find out.  Tom Linden
has
been a good correspondent on this topic and I am getting some good information
from him.

I next teach this class in the Spring Quarter.  I hope to have a short unit that
covers
PL/I since it was a major development in the evolution of programming languages.
In that unit, I would like to be able to give the students accurate information
about
the language.

Richard Riehle



0
adaworks2 (748)
1/1/2006 6:44:17 PM

Peter Flass wrote:

[snip]

> We are in agreement here.  This was a mistake, although not a major one. 
>  I usually code "ON ENDFILE(x) EOF_x = '1'b;", and then say "READ 
> FILE(x)...; IF EOF_x THEN...".

I seem to remember doing (its been about 25 years)

eof=1b;
on endfile(X) eof=0b;
read file(X);
do while(eof);
   process record;
   read file(X);
   end;

I know tehre is an extra read, but this worked better in the PL/1 
compiler I used.  At that time there was no UNTIL in the compiler I was 
using.
0
multicsfan (63)
1/1/2006 6:58:54 PM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:qdUtf.6827$2j2.3540@fe11.lga...
> Tom Linden wrote:
> > Setjmp and longjmp are primitive copies of the PL/I signalling mechanisms
> > and lack semantic analysis.
>
> I doubt that PL/I had much to do with it. PL/I was the first HLL to
> implement exception handling -- but the concept already existed at the
> assembler-language level.
>
> > John,  I really don't understand what you are saying.  PL/I condition
> > handling is not at all complex.  In fact it is a simple as you can make it
> > and still provide the power that it does.  Moreover, there is nothing
> > unpredictable with the semantics, that i am aware of.  Could you please
> > provide an example to amplify your assertion?

I am glad we are back on this subject.   Exception handling has been implemented
in various ways for different languages.  The conditions under which exceptions
are
raised also varies.

In an earlier posting, I asked about support for pre-conditions and
post-conditions.
It seems invariants are implemented using ON-conditions in PL/I.   I will need
to
look at that more closesly, but there is still the question of pre- and
post-conditions.

Consider (in pseudo code)

                procedure zzyzzg (x : integer; y : float; z : character)
                       require y >= 0 and x in 0 .. 256;
                       [local variables declared here ]
                do
                        [ algorithmic code ]
               end
                     ensure x after = x + 1;

This is a rather elementary example.  I can provide far more sophisticated
examples if necessary.  The pre- and post-conditions are tightly bound to
the procedure mechanism, not the just the data.   Further, they can be stated
as part of contract (to support separate compilation) independently of the
implementation.   So we might have the above in a specification module as:

                procedure zzyzzg (x : integer; y : float; z : character)
                       require y >= 0 and x in 0 .. 256;
                       ensure x after = x + 1;

This is a contract (as in design by contract) and the caller of this procedure
needs to know nothing of the internals, but does have a specification that
rigorously defines the conditions under which the procedure can fail.  These
conditions return an boolean result.   In some cases we are more interested
in the boolean result that we are a true exception.  Different languages
have different rules for this sort of thing and it is a continuing topic of
research
in computer science.

If the pre-condition (require) fails, an exception is raised to the caller.   If
the
post-condition (ensure) fails, we also get an exception.  The exception handler
for the post-condition can be invoked immediately following the failure
of ensure, or be propogated to the caller.

There is a relationship between the pre-condition and the post-condition.   We
have
the notion of "weakest" pre-condition where the post-condition cannot be
stronger than the pre-condition.

There are also pre-condition mechanisms that act as simple "guards."  These
are set up so the called procedure (usually in a concurrent entity) will block
until the condition is true.  How we design that blocking is a bit tricky since
we do not want to halt an entire system.

I see how the PL/ CONDITION feature supports invariants.  I am not certain
how it corresponds to pre- and post-conditions.  I will provide more examples
later if it would help.

Richard Riehle



0
adaworks2 (748)
1/1/2006 7:13:52 PM
"Tom Linden" <tom@kednos.com> wrote in message
news:ops2olvrjtzgicya@hyrrokkin...
>
> Ada is a dead language from a market acceptance point of view.  You might
> claim the same for PL/I; however, I would venture to guess that the number
> of lines of code of PL/I to Ada in production is likely 100000:1 if not
> more.
>
Ada continues to evolve and find a following among people in the safety-critical
community.   It is used in commercial flight avionics and other aircraft
systems.
The European Space Agency is a big user.   We continue to develop military
software in Ada.   It has widespread use in transportation systems such as
railway switching and control.   And it is used for communication satellites,
and other space applications.   It is not used much by those programming
desktop systems, and seems also true of PL/I.

I hear people say things such as COBOL is a deal language.  Or refer to
some other languages they don't hear about much as being dead.  There
are probably more lines of code in COBOL, and still be developed, than there
are in C++, PL/I, Ada, and Java combined.  That's just a guess.

I know of development groups who still write Jovial code and swear that it is
superior to any other language in existence.   Others think that C++ is the
greatest thing to happen to programming, without argument.   Some experienced
developers have chosen Ruby and will never go back to anything before it.  I
have a colleague who writes beautiful software, highly sophisticated
applications
in Lisp.   "Why would anyone want to use anything else," he asks.

Everyone of those people mentioned above is as intelligent and as well-educated
about software as you, or me, or any of the other contributors to this forum.
They
have made their choice based on sound reasoning, given their particular
premises.

Some of them will readily admit that their choice is not ideal.  There is no
ideal programming
language -- not even Ada or PL/I.or Eiffel or ...    A given language might be
considered
ideal by one person who has a fondness for the accomplishments he/she has been
able
to achieve in that language, but one person's ideal is not another's.

I know you understand this well Tom since you have a lot of experience and are
able
to see the pros and cons of such things.

Finally, Ada 2005, an ISO standard, is soon ready.   And there are a lot of
people I know
who are looking forward to using it.

Richard Riehle



0
adaworks2 (748)
1/1/2006 7:30:51 PM
On Sun, 01 Jan 2006 19:13:52 GMT, <adaworks@sbcglobal.net> wrote:

> Consider (in pseudo code)
>                procedure zzyzzg (x : integer; y : float; z : character)
>                        require y >= 0 and x in 0 .. 256;
>                        [local variables declared here ]
>                 do
>                         [ algorithmic code ]
>                end
>                      ensure x after = x + 1;

Your pre- and post-assertions are simply tests that would be executed in  
the
prolog and epilog,  respectively.  I can see some value in hiding the tests
and letting the compiler generate the code in these sections, particularly
since there could be multiple entry points as well multiple exits from a
procedure.  Thus the information could be provide by either the caller or
the callee.  Now I haven't thought this through but I think a consistent
definition might fall along the following lines

dcl x entry( fixed bin(15) range(0,10) signal(f),
              char(20)) external returns(fixed bin(15) range(1,100)  
signal(y));

x: proc(a,c) returns (fixed bin(15) range(1,1000) signal(r);
dcl a fixed bin(15) range(1,1000) signal(x),
     c char(20);

So the interpretation would go like this:  The proc statement, if ranges  
are supplied
will establish the appropriate tests in the prolog and epilog, which may  
be regarded
as the default assertions for that procedure.  The declaration in the  
calling program
establishes new assertions to override the default one,  the signal  
generated if
assertion is invalidated could either be the default one or the one  
supplied by the
callee.  I think this would be pretty easy to implement, and would only  
require some
extensions to the stack frame.  Also note, no new keywords, just reused  
them in new
context, so no ambiguity.  I used numbers for the ranges, but there is no  
reason why
this couldn't be any valid PL/I expression. The handlers for the  
conditions, f,x, and y
would still need to be coded somewhere.  In fact, you could make the  
conditions a
subscripted array such as f(i)  then you could write, for example

%replace SalaryTooLarge by 1:
$replace SalaryTooSmall by 2;

dcl salary fixed decimal(8,2)
            range(lower,upper)
            signal(f(SalaryTooSmall),f(SalaryTooLarge));

Just some thoughts
0
tom284 (1839)
1/1/2006 8:31:13 PM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:l7Rtf.69073$ME5.15991@twister.nyroc.rr.com...
> John W. Kennedy wrote:
>  > The designers of
> > PL/I looked as assembler, and drew the obvious, but wrong conclusion,
> > "Exception handlers are enabled by executable statements." C, to the
> > extent that it can be said to have exception handlers, did the same, but
> > at least defined them with GOTO logic, mimicking the underlying
> > operating-system constructs.
>
> You have said this before, and I have been considxering your thoughts
> before adding my $.02 (d@mn PeeCee keyboards don't have a "cent" sign.)
>
> As usual with PL/I, its design provides the most flexibility.  It is
> entirely possible to mimic the exception-handling constructs of other
> languages in PL/I, but not (AIUI) the reverse.  If you want Java's (and
> C++'s?) 'try/catch', or if you want lexical rather than dynamic scoping,
> then just code the ON-statement before the statement or block being
> checked, and the corresponding REVERT afterwards. If you want C's model,
> just code a GOTO as the ON-Unit.  If you like the assembler model, as I
> do, then stick with the dynamic model, which provides, I would say.
> "defense in depth" with the innermost ON-Unit providing the most
> specific recovery possibilities, and successively outer ones more
> general recovery, of the nature of "terminate thread and exit."
>
> As I've mentioned before, having executable rather than declarative
> ON-Statements allows the possibility of selecting alternative error
> handing logic at run-time, rather than having to re-compile the program
> to change the action.  Therefore the standard action might be just print
> a message and terminate.  A run-time switch would allow the programmer
> to execute an "ON ERROR PUT DATA" statement, or other debugging tools.

Well said, Peter.
    And if I may add a further note, such run-time switch could
be activated during run time (via the ATTENTION interrupt)
should the programmer decide that the computation has gone bad
or suspicious.

> > Another PL/I idea universally rejected has been the notion of using
> > exception handlers to deal with expected conditions. Its utility for
> > certain cases of ENDPAGE is undeniable, but there are real-world
> > circumstances that ENDPAGE fails to serve, and the ENDPAGE semantics
> > nevertheless complicate. The use of exception handlers to handle
> > expected end-of-input, on the other hand, is universally eschewed (which
> > is why the ENDFILE() function has been belatedly added).

> We are in agreement here.  This was a mistake, although not a major one.
>   I usually code "ON ENDFILE(x) EOF_x = '1'b;", and then say "READ
> FILE(x)...; IF EOF_x THEN...".

There may not be much difference between ENDFILE condition and
function in this particular case, but the function is impractical
for stream input, having to test for end-of-file after each element is input.


0
robin_v (2737)
1/1/2006 11:12:18 PM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:N0_sf.61054$ME5.42387@twister.nyroc.rr.com...
> Tom Linden wrote:

> > I had somwhere a paper called something like "On the PL/I Signalling
> > Mechanism" Don't recall the author, but i think it was in Sigplan, maybe
> > late 60's,  Peter probably has a copy.
>
> Maybe "Exception handling in PL/I" by M Donald McClaren (1977)?
> http://doi.acm.org/10.1145/800022.808316

I think that that is the one.  It appeared in several publications,
including SIGPLAN Notices.

            Exception handling in PL/I
            Author M. Donald MacLaren  Research and Development, Digital
                  Equipment Corporation, 146 Main Street, Maynard, Massachusetts

      ABSTRACT
      The PL/I language's facilities for handling exceptional conditions are
      analyzed. The description is based on the new PL/I standard. Special
      attention is given to fine points which are not well known. The analysis
      is generally critical. It emphasizes problems in regards to implementation
      and structured programming. A few suggestions for future language design
      are offered.


0
robin_v (2737)
1/1/2006 11:12:19 PM
On Sun, 01 Jan 2006 23:12:19 GMT, robin <robin_v@bigpond.com> wrote:

> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
> news:N0_sf.61054$ME5.42387@twister.nyroc.rr.com...
>> Tom Linden wrote:
>
>> > I had somwhere a paper called something like "On the PL/I Signalling
>> > Mechanism" Don't recall the author, but i think it was in Sigplan,  
>> maybe
>> > late 60's,  Peter probably has a copy.
>>
>> Maybe "Exception handling in PL/I" by M Donald McClaren (1977)?
>> http://doi.acm.org/10.1145/800022.808316
>
> I think that that is the one.  It appeared in several publications,
> including SIGPLAN Notices.
>
>             Exception handling in PL/I
>             Author M. Donald MacLaren  Research and Development, Digital
>                   Equipment Corporation, 146 Main Street, Maynard,  
> Massachusetts
>
>       ABSTRACT
>       The PL/I language's facilities for handling exceptional conditions  
> are
>       analyzed. The description is based on the new PL/I standard.  
> Special
>       attention is given to fine points which are not well known. The  
> analysis
>       is generally critical. It emphasizes problems in regards to  
> implementation
>       and structured programming. A few suggestions for future language  
> design
>       are offered.
>
Should have remembered that, he was the PL/I expert in the team that ported
our PL/I compiler to the VAX!  See "Engineering a Vompiler, VAX Code  
Generation
and Optimization" by Anklam, Cutler, Heinen & MacLaren  ISBN 0-932376-19-3

0
tom284 (1839)
1/1/2006 11:12:24 PM
John W. Kennedy wrote:
> 
> The language is in limbo as to whether the following will crash when x 
> is zero:
> 
>   if x ^= 0 & y/x < 10 then ...
> 
> Some compilers, as a side-effect of optimization, will compile it as 
> though it were C
> 
>   if (x != 0 && y/x < 10) ...
> 
> or Ada
> 
>   if x /= 0 and then y/x < 10 then ...
> 
> but the definition of the language actually implies C
> 
>   if (x != 0 & y/x < 10) ...
> 
> or Ada
> 
>   if x /= 0 and y/x < 10 then ...
> 

If I understand your C or Ada correctly, the language doesn't imply, but 
specifies this.  Reflecting further on the standard, I believe 
conditionals are supposed to be completely evaluated to return a BIT(1) 
result (boolean) which is then tested.

'IF a=b AND c=d' is supposed to evaluate both conditions and then AND 
the result bits.  I understand why short-circuiting was instituted, but 
it "really" isn't correct.

0
Peter_Flass (956)
1/1/2006 11:40:12 PM
John W. Kennedy wrote:
John - your example is a bit *too* simple, since it just raises the 
ERROR condition.  I think I see where you're going on this, but as I 
said, you can model the exception-handling of (I believe) *any* other 
language in PL/I.  Sure, you get lots of rope to hang yourself with 
nonsensical code, but the language only provides the tools.  How you use 
or misuse them is your own business.

A better example might be:
   sample: PROC(x);
     SELECT(x);
       WHEN(1) DO;
         ON CONDITION(foo) PUT DATA;
         END;
        WHEN(2) DO;
          ON CONDITION(foo) DO;
            PUT SKIP LIST( 'foo condition raised' );
            END;
        WHEN(3) DO;
           <some other action to be taken for foo>
           END
         END; /* select */
     <do sone stuff>
     IF <whatever> THEN SIGNAL CONDITION(foo);
     END sample;

Why would a rational programmer want to mix up ON and SIGNAL statements 
in a SELECT-group?  Just because you *can* doesn't mean you *should*.

> 
> SAMPLE: PROCEDURE (X) RECURSIVE;
>   DECLARE X FIXED BINARY;
>   SELECT (X)
>     WHEN (1)
>       ON CONDITION (FOO)
>         PUT SKIP DATA (X);
>     WHEN (3)
>       SIGNAL CONDITION (FOO);
>     WHEN (5)
>       RETURN;
>     OTHERWISE;
>   END;
>   PUT SKIP DATA (X);
>   CALL SAMPLE (X + 1);
> END SAMPLE;
> 
> CALL SAMPLE (0);
> 
> 

0
Peter_Flass (956)
1/1/2006 11:53:37 PM
adaworks@sbcglobal.net wrote:
> "Tom Linden" <tom@kednos.com> wrote in message
> news:ops2olvrjtzgicya@hyrrokkin...
> 
>>Ada is a dead language from a market acceptance point of view.  You might
>>claim the same for PL/I; however, I would venture to guess that the number
>>of lines of code of PL/I to Ada in production is likely 100000:1 if not
>>more.
>>
> 
> Ada continues to evolve and find a following among people in the safety-critical
> community.   It is used in commercial flight avionics and other aircraft
> systems.
> The European Space Agency is a big user.   We continue to develop military
> software in Ada.   It has widespread use in transportation systems such as
> railway switching and control.   And it is used for communication satellites,
> and other space applications.   It is not used much by those programming
> desktop systems, and seems also true of PL/I.
> 
> I hear people say things such as COBOL is a deal language.  Or refer to
> some other languages they don't hear about much as being dead.  There
> are probably more lines of code in COBOL, and still be developed, than there
> are in C++, PL/I, Ada, and Java combined.  That's just a guess.
> 
> I know of development groups who still write Jovial code and swear that it is
> superior to any other language in existence.   Others think that C++ is the
> greatest thing to happen to programming, without argument.   Some experienced
> developers have chosen Ruby and will never go back to anything before it.  I
> have a colleague who writes beautiful software, highly sophisticated
> applications
> in Lisp.   "Why would anyone want to use anything else," he asks.
> 
> Everyone of those people mentioned above is as intelligent and as well-educated
> about software as you, or me, or any of the other contributors to this forum.
> They
> have made their choice based on sound reasoning, given their particular
> premises.
> 
> Some of them will readily admit that their choice is not ideal.  There is no
> ideal programming
> language -- not even Ada or PL/I.or Eiffel or ...    A given language might be
> considered
> ideal by one person who has a fondness for the accomplishments he/she has been
> able
> to achieve in that language, but one person's ideal is not another's.

Different languages exist for different purposes.  Most are very 
specific for very specialized applications:

	BASIC is ideal for quick and dirty interaction
	Forth is great for programming robotics interactively
	APL is terrific for solving a class of problems you wouldn't want to 
try in any other language
	Fortran for computation
	Cobol for business apps
	Visual Basic is really good for fast creation of Windows GUIs
	C if you're too lazy to learn assembler (and want to shoot yourself in 
the foot)
	C++ if you want bloatware (and want to blow off your hip -- Bjarne's 
quotes, not mine)
	Lisp for list processing with lots of recursion and self-modifying code
	I could go on...

Then we come to PL/I.  It is not particularly a superior language for 
any specific application, but it is the superior work-horse 
utility-infielder language for all purposes.  What I mean by this is 
that if you were tasked with a wide variety of programming applications 
and could only have one language (assembler excluded), PL/I is the ideal 
choice.

Ada comes the closest to PL/I in this regard, but I find it's syntax 
abominable.  And, by the way, having spent most of my career in 
aerospace I have observed that there are far more applications being 
written in something else rather than in Ada including those products 
delivered to DoD.  (Boeing uses Ada, but as an insider I can tell you it 
was a major stuggle to ultimately achieve acceptable results -- some 
projects were delayed over a year because of it.)  Contemporary compiler 
implementations and better programmer training have overcome most of 
these initial difficulties.

> 
> I know you understand this well Tom since you have a lot of experience and are
> able
> to see the pros and cons of such things.
> 
> Finally, Ada 2005, an ISO standard, is soon ready.   And there are a lot of
> people I know
> who are looking forward to using it.
> 
> Richard Riehle
> 
> 
> 
0
donaldldobbs (108)
1/2/2006 12:02:09 AM
This was my conclusion as well, and that of others independently.  As a 
result PLIGCC is developing a free front-end to GCC, and I'm building a 
low-cost x86 compiler.  At some point, I would also expect to see the 
Multics compiler ported to modern hardware.

multicsfan wrote:

> 
> 
> Peter Flass wrote:
> 
>> Tom Linden wrote:
> 
> [snip]
> 
>>  From limited knowledge I'd thing Ada is more of a niche language than 
>> PL/I, being largely (AFAIK) confined to defense and similar markets. 
>> PL/I has more breath (sp?) of use  but probably not much more depth.
>> I'd like to see this change in the future.  PL/I is superior to C 
>> (probably no argument here), and could surpass C++ with a few 
>> additions, as Peter's paper shows.  Now that hardware is no longer too 
>> limited to support PL/I effectively, I'd like to see it move in on C, 
>> due to its obvious superiority.
> 
> 
> The biggest reason C took over was C compilers were free or low cost 
> compared to PL/1.  Gcc is free and runs on just about everything.  I 
> looked at buying a PL/1 compiler several times, but each time I was able 
> to afford to pay more, the price went up just outside what I was willing 
> to pay.  The first one I was able to afford was the IBM Personal which 
> at that time was OS/2 only and I could not get OS/2 to load on my computer.

0
Peter_Flass (956)
1/2/2006 12:05:07 AM
robin wrote:
> 
> There may not be much difference between ENDFILE condition and
> function in this particular case, but the function is impractical
> for stream input, having to test for end-of-file after each element is input.
>  
Interesting point, which I hadn't considered.  You could awlays do it 
the C way: return as much data as you got, have the ENDFILE builtin 
return true, and let the programmer sort out what he's got.

0
Peter_Flass (956)
1/2/2006 12:11:26 AM
It is unlikely at this time that the Multics PL/1 compiler or Multics 
system will ever be released.  Honeywell or Bull or whoever owns the 
rights has been unwilling to release anything.  The only code that has 
been 'released' is a very old version developed with government funds 
around MR4/MR5 IIRC.  The latest MR12 is basically in limbo.

I do know the compiler was very fast to compile and generated very good 
code.  For those who are famalier my comparison was done between a 6180 
cpu w/cache and an IBM 360/67 running several copies of MVT under CP-67. 
  The machines are about the same performance +- a little bit according 
to the instruction timings in the manuals.  I had converted a number 
cruncher program from Multics PL/1 to Fortran VI.  The compile and run 
times were compared with the following result:

the Multics PL/1 compiler compiled the PL/1 program as fast as WATFIV 
on the 67 compiled the fortran program.  The Multics run time was about 
the same as that of the code compiled with IBM fortran-H OPT=2.

My general experience with writing software on both machines tended to 
show about the same results although I never did any other comparisons.

I'm having vision problems or I'd try to get active with the PL!GCC 
project though I'm not sure how well a front end to GCC will be able to 
produce equivalent code for GCC.

One of the options I've always thought PL/1 should have is an 
options(binary) to tell the compiler to assume all constants can be 
converted to binary from to match the operand they are being used with. 
  This avoids the inexperienced PL/1 scientific programmer from getting 
bit by using decimal constants.


Peter Flass wrote:

> This was my conclusion as well, and that of others independently.  As a 
> result PLIGCC is developing a free front-end to GCC, and I'm building a 
> low-cost x86 compiler.  At some point, I would also expect to see the 
> Multics compiler ported to modern hardware.
> 
> multicsfan wrote:
> 
>>
>>
>> Peter Flass wrote:
>>
>>> Tom Linden wrote:
>>
>>
>> [snip]
>>
>>>  From limited knowledge I'd thing Ada is more of a niche language 
>>> than PL/I, being largely (AFAIK) confined to defense and similar 
>>> markets. PL/I has more breath (sp?) of use  but probably not much 
>>> more depth.
>>> I'd like to see this change in the future.  PL/I is superior to C 
>>> (probably no argument here), and could surpass C++ with a few 
>>> additions, as Peter's paper shows.  Now that hardware is no longer 
>>> too limited to support PL/I effectively, I'd like to see it move in 
>>> on C, due to its obvious superiority.
>>
>>
>>
>> The biggest reason C took over was C compilers were free or low cost 
>> compared to PL/1.  Gcc is free and runs on just about everything.  I 
>> looked at buying a PL/1 compiler several times, but each time I was 
>> able to afford to pay more, the price went up just outside what I was 
>> willing to pay.  The first one I was able to afford was the IBM 
>> Personal which at that time was OS/2 only and I could not get OS/2 to 
>> load on my computer.
> 
> 
0
multicsfan (63)
1/2/2006 1:06:10 AM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:l7Rtf.69073$ME5.15991@twister.nyroc.rr.com...
> You have said this before, and I have been considxering your thoughts
> before adding my $.02 (d@mn PeeCee keyboards don't have a "cent" sign.)

You mean 2� ?


0
robin_v (2737)
1/2/2006 2:50:21 AM
"Tom Linden" <tom@kednos.com> wrote in message
news:ops2pvabr2zgicya@hyrrokkin...
> On Sun, 01 Jan 2006 19:13:52 GMT, <adaworks@sbcglobal.net> wrote:
>
> > Consider (in pseudo code)
> >                procedure zzyzzg (x : integer; y : float; z : character)
> >                        require y >= 0 and x in 0 .. 256;
> >                        [local variables declared here ]
> >                 do
> >                         [ algorithmic code ]
> >                end
> >                      ensure x after = x + 1;
>
> Your pre- and post-assertions are simply tests that would be executed in
> the
> prolog and epilog,  respectively.  I can see some value in hiding the tests
> and letting the compiler generate the code in these sections, particularly
> since there could be multiple entry points as well multiple exits from a
> procedure.  Thus the information could be provide by either the caller or
> the callee.  Now I haven't thought this through but I think a consistent
> definition might fall along the following lines
>
> dcl x entry( fixed bin(15) range(0,10) signal(f),
>               char(20)) external returns(fixed bin(15) range(1,100)

[unmatched definition of proc x]

> signal(y));
>
> x: proc(a,c) returns (fixed bin(15) range(1,1000) signal(r);
> dcl a fixed bin(15) range(1,1000) signal(x),
>      c char(20);

Could not these tests on A be provided by INITIAL CALL?
dcl a fixed bin initial call range (a, 1, 1000);
or, of course, by a simple statement:
range(a, 1, 1000);
Similarly, prior to returning, a range check like the previous line.


0
robin_v (2737)
1/2/2006 2:50:22 AM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:j2Utf.6823$2j2.2284@fe11.lga...

> Will you, for God's sake, spend some time this year looking in a mirror?

Why don't you?

> I spent /decades/ pushing PL/I, supporting PL/I, and coding in PL/I, and
> I'm still angry at the "If IBM created it, it must be evil," attitude

IBM got its bad name from predatory and monopolistic tactics.

> that kept PL/I from becoming, in its time, the universal language for
> general programming.

IBM created FORTRAN, and it became very popular.

> You'll find me quoted by name in a late-60's
> pro-PL/I IBM publication. I personally added 73-80 sequence checking,
> the column-1 convention,

We used columns 1-80 for PL/I source programs.
Using 2-72 caused unnecessary errors by being "one column out".
%PAGE; and %SKIP; were superior, portable ways to organize
the listing (or even just a few blank lines! or rather, blank cards).

> and the %INCLUDE statement to the PL/I (D)
> compiler for my site, and my employer once sent me as an ambassador to
> Hursley Labs to discuss language improvements.
>
> But your repeated unreasoning assertions that every choice made by
> PL/I's designers forty years ago was wiser and better informed than the
> subsequent decisions of language designers

You're being completely irrational.  I make no such claims.

> with years of experience and
> hindsight are nothing but an embarrassment to those of us who still
> retain an affection for the old girl. You've become nothing but the
> mirror image of David Frank, trapped in a quasi-religious One True Way
> that has stunted your ability to think and learn.

Flattery will get you anywhere.

Your basic problem is that you resort to insults when someone
disagrees with you.

> PL/I made major mistakes. Run-time-set exception handling was a mistake.

You keep saying that, but you are mistaken.

> Confusing exception handling with expected-condition handling was a
> mistake.

No it wasn't, and I have given in this forum at least two
instances where run-time handling is essential.
   1.    The ENDFILE condition is essential for stream input.
    2.    Run-time alteration of error handling. (Peter Flass has
           mentioned this also).
    3.    ENDPAGE condition handling is a nice way of
           dealing with end of page, and is like a user-defined condition.
           It is good to be told when the end-of page is here, without
           having to test for it after every line (especially when that line
           may arrive during data transmission of multiple lines from a single
          PUT statement).  In other words, what you are suggesting
          is entirely impractical.  The designers of PL/I got it right
          first time.

> One-size-fits-all fixed-point precision rules were a mistake.

They work in the general case.  If you don't want to use them,
you can use ADD, SUBTRACT, MULTPLY, and DIVIDE.
That's what they are for.

> Failure to distinguish between integer and generalized fixed-point
> arithmetic was a mistake.

It's not a "mistake".  You can get integer arithmetic simply,
as we have illustrated before: dcl k type integer;

> Anonymous pointers were a mistake.

Some would disagree.

> Failure to
> distinguish boolean from short-circuit logic operators was a mistake.

A reasonable design, clearly defined.

> The original PL/I tasking model was a mistake (which is why it was
> abandoned).
>
> And in recent years, PL/I has fallen behind new developments.

Please don't talk nonsense.  A lot of things were added in recent years,
including strong typing, typed pointers, a DATE type (windowed Y2K
date handling), enumerated types, a host of date functions,
and many new builtins, C-compatible strings, unsigned arithmetic,
to mention some.

> No OO facilities. No range checking.

It's  already there with SIZE, and in addition you can do this trivially
with the preprocessor, in conjunction with user-defined conditions.

> The old tasking model has been dropped,
> but the new one is at a stone-ax level.

Only IYO.

> The verbose and unnecessary
> GENERIC attribute is still in use where modern languages have automatic
> overloading,

Only IYO.

> and the macro language is an unnecessarily complex way to
> handle the problem dealt with in C++ by "templates" and in Ada by "generic".
>
> > That was because it was so far advanced when it was introduced.
> > It didn't need anything much done to it.
>
> Ac ille respondens ait: tu dicis.
>
> The world has moved on since 1965.

So has PL/I.

> Deal with it.

Again, you resort to insults when you don't like others' opinions.


0
robin_v (2737)
1/2/2006 2:50:23 AM
"multicsfan" <multicsfan@hotmail.com> wrote in message
news:ODVtf.2746$tJ1.1354@trndny01...
>
> I seem to remember doing (its been about 25 years)
>
> eof=1b;
> on endfile(X) eof=0b;
> read file(X);
> do while(eof);
>    process record;
>    read file(X);
>    end;
>
> I know tehre is an extra read, but this worked better in the PL/1
> compiler I used.  At that time there was no UNTIL in the compiler I was
> using.

The following needs only one read:-

on endfile (x) go to complete;
do forever;
   read file (x) into (d);
   <<process record>>
end;
complete:


0
robin_v (2737)
1/2/2006 2:50:24 AM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:qdUtf.6827$2j2.3540@fe11.lga...
> Tom Linden wrote:
> > Setjmp and longjmp are primitive copies of the PL/I signalling mechanisms
> > and lack semantic analysis.
>
> I doubt that PL/I had much to do with it. PL/I was the first HLL to
> implement exception handling -- but the concept already existed at the
> assembler-language level.

Which hardware prior to S/360 offered exception handling?

> > John,  I really don't understand what you are saying.  PL/I condition
> > handling is not at all complex.  In fact it is a simple as you can make it
> > and still provide the power that it does.  Moreover, there is nothing
> > unpredictable with the semantics, that i am aware of.  Could you please
> > provide an example to amplify your assertion?
>
> SAMPLE: PROCEDURE (X) RECURSIVE;
>    DECLARE X FIXED BINARY;
>    SELECT (X)
>      WHEN (1)
>        ON CONDITION (FOO)
>          PUT SKIP DATA (X);
>      WHEN (3)
>        SIGNAL CONDITION (FOO);
>      WHEN (5)
>        RETURN;
>      OTHERWISE;
>    END;
>    PUT SKIP DATA (X);
>    CALL SAMPLE (X + 1);
> END SAMPLE;
>
> CALL SAMPLE (0);

What is semantically "unpredictable" about this?

> > Unexpected conditions, what does that really mean?  Well, if I venture a
> > guess
> > it would have to be, we got an error but we don't what it is.  This happens
> > in any language, so is a degenerate case, derived from poor programming
> > practice
> > and not worthy of further consideration in the current context.  PL/I
> > provides a set
> > of standard signals, of which you have mention several, and these are
> > mundane
> > for purposes of this discussion.  it is the user generated signals that are
> > important for writing fault tolerant code, and that can only be done by
> > those
> > initmate with the application.  Properly employed, signals provide
> > precisely the
> > assertion mechanisms that Richard questioned earlier in this thread
>
> The issue is that PL/I uses ON-conditions as the standard access to
> non-errors (most notably ENDFILE) that should instead be accessible by
> simple IF tests.

That is a furphy.  It is impractical for stream input.
Without the ON condition, you couldn't write GET (A);
[where A is an array].


0
robin_v (2737)
1/2/2006 2:50:25 AM
"multicsfan" <multicsfan@hotmail.com> wrote in message
news:xjVtf.5646$gq4.393@trndny04...
> The first one I was able to afford was the IBM Personal which
> at that time was OS/2 only and I could not get OS/2 to load on my computer.

Perseverence.  OS/2 will load on a PC.
You can probably still get Warp 4, or maybe even Warp 3.
Maybe even Ver 2.


0
robin_v (2737)
1/2/2006 2:50:26 AM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:jGTtf.13706$L75.10549@fe12.lga...

> The language is in limbo as to whether the following will crash when x
> is zero:
>
>    if x ^= 0 & y/x < 10 then ...

That is a programming error.  Why do you expect that it will not crash
when x is zero?


0
robin_v (2737)
1/2/2006 2:50:26 AM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:esRtf.69310$ME5.34886@twister.nyroc.rr.com...
> Tom Linden wrote:
>
> > On Sat, 31 Dec 2005 21:59:44 -0500, John W. Kennedy
> > <jwkenne@attglobal.net> wrote:
> >
> >> The truth? PL/I was a /huge/ leap
> >> forward  among languages compilable to reasonably efficient object
> >> code in the  mid-60's, and, with a few improvements, would still be
> >> viable today (OO  and a concrete distinction between boolean and
> >> short-circuit operators,  at present left to the vagaries of the
> >> compiler's optimizing pass, would  be a start).
> > Could you explain what you mean by that?
>
> This *is* a potential problem.  The incorrect, but nearly universal,
> usage is something like: "IF p^=NULL & p->whatever=...", which obviously
> depends on the IF-statement evaluation being short-circuited before
> evaluating the second condition if p is NULL.

Why is this a problem?  Whether IF p^=NULL &: p->whatever=...
or IF p^=NULL THEN IF ...
the programmer still has to code it.
The first is gobbledigook, while the second is absolutely clear
and unequivocal.

>  [for the record, I now
> try to avoid this by saying "IF p^=NULL THEN IF...".  The boolean
> version of this is "b = (p^=NULL) & (p->whatever)...

No, the Boolean version is
    b = p^=NULL; IF b THEN b = p->whatever;

You can RYO short circuit:

IF SHORT_CIRCUIT( (p^=NULL) & (p->whatever) ) THEN ...

and b = SHORT_CIRCUIT( (p^=NULL) & (p->whatever) );

>  I have put in
> logic to short-circuit the evaluation in the first case, but not in the
> second.  Without checking, I'd have to believe offhand that the standard
> is no short-circuiting in all cases.  This should be defined explicitly,
> even if only in the terms above.


0
robin_v (2737)
1/2/2006 2:50:27 AM
"Tom Linden" <tom@kednos.com> wrote in message
news:ops2powoxpzgicya@hyrrokkin...
> On Sun, 01 Jan 2006 11:45:00 -0500, John W. Kennedy
> <jwkenne@attglobal.net> wrote:
>
> > The language is in limbo as to whether the following will crash when x
> > is zero:
> >    if x ^= 0 & y/x < 10 then ...
> >
> No limbo ther, it should crash.  The correct (safe) way to code this is
>
> if x ^= 0 then if  y/x < 10 then
>
> or with our compiler
>
> if x ^= 0 &: y/x < 10 then

That is non-PL/I syntax.  Better is --
     if x ^= 0 then if  y/x < 10 then ...


0
robin_v (2737)
1/2/2006 2:50:27 AM
On Mon, 02 Jan 2006 02:50:27 GMT, robin <robin_v@bigpond.com> wrote:

> "Tom Linden" <tom@kednos.com> wrote in message
> news:ops2powoxpzgicya@hyrrokkin...
>> On Sun, 01 Jan 2006 11:45:00 -0500, John W. Kennedy
>> <jwkenne@attglobal.net> wrote:
>>
>> > The language is in limbo as to whether the following will crash when x
>> > is zero:
>> >    if x ^= 0 & y/x < 10 then ...
>> >
>> No limbo ther, it should crash.  The correct (safe) way to code this is
>>
>> if x ^= 0 then if  y/x < 10 then
>>
>> or with our compiler
>>
>> if x ^= 0 &: y/x < 10 then
>
> That is non-PL/I syntax.  Better is --
>      if x ^= 0 then if  y/x < 10 then ...
>
less so than varingz
0
tom284 (1839)
1/2/2006 3:51:49 AM
On Mon, 02 Jan 2006 02:50:22 GMT, robin <robin_v@bigpond.com> wrote:

> "Tom Linden" <tom@kednos.com> wrote in message
> news:ops2pvabr2zgicya@hyrrokkin...
>> On Sun, 01 Jan 2006 19:13:52 GMT, <adaworks@sbcglobal.net> wrote:
>>
>> > Consider (in pseudo code)
>> >                procedure zzyzzg (x : integer; y : float; z :  
>> character)
>> >                        require y >= 0 and x in 0 .. 256;
>> >                        [local variables declared here ]
>> >                 do
>> >                         [ algorithmic code ]
>> >                end
>> >                      ensure x after = x + 1;
>>
>> Your pre- and post-assertions are simply tests that would be executed in
>> the
>> prolog and epilog,  respectively.  I can see some value in hiding the  
>> tests
>> and letting the compiler generate the code in these sections,  
>> particularly
>> since there could be multiple entry points as well multiple exits from a
>> procedure.  Thus the information could be provide by either the caller  
>> or
>> the callee.  Now I haven't thought this through but I think a consistent
>> definition might fall along the following lines
>>
>> dcl x entry( fixed bin(15) range(0,10) signal(f),
>>               char(20)) external returns(fixed bin(15) range(1,100)
>
> [unmatched definition of proc x]
>
>> signal(y));
>>
>> x: proc(a,c) returns (fixed bin(15) range(1,1000) signal(r);
>> dcl a fixed bin(15) range(1,1000) signal(x),
>>      c char(20);
>
> Could not these tests on A be provided by INITIAL CALL?
> dcl a fixed bin initial call range (a, 1, 1000);
> or, of course, by a simple statement:
> range(a, 1, 1000);
> Similarly, prior to returning, a range check like the previous line.
>
Yes, of course, they could, the question or rather the challenge was  
whether
a consistent form could be construct to embed it in the compiler, of  
course,
it could be completely generalized and not limited to an holonomic  
constraint

0
tom284 (1839)
1/2/2006 3:54:28 AM
Short-circuit evaluation is not only not the default, it can basically be 
assumed that it will not be applied.

I recently had a PMR in which the library routine for char -> float gave an 
8094 when the last char of the float was at the last byte boundary of 
allocation memory. The cause was a condition "past the end of the string or 
character isn't permitted". The defect has been corrected and will no doubt 
be part of fix pack 14.

"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message 
news:esRtf.69310$ME5.34886@twister.nyroc.rr.com...
> Tom Linden wrote:
>
>> On Sat, 31 Dec 2005 21:59:44 -0500, John W. Kennedy 
>> <jwkenne@attglobal.net> wrote:
>>
>>> adaworks@sbcglobal.net wrote:
>>>
>>>> "robin" <robin_v@bigpond.com> wrote in message
>>>> news:uAqtf.147381$V7.484@news-server.bigpond.net.au...
>>>>
>>>>> Can what you have wirtten in this post be described as "rant"?
>>>>>
>>>> This is my last communication with you.   It is clear you have no 
>>>> respect
>>>> for anything I might say and that makes conversation between us 
>>>> useless.
>>>
>>>
>>> I'm afraid Robin is a fanatic. The truth? PL/I was a /huge/ leap forward 
>>> among languages compilable to reasonably efficient object code in the 
>>> mid-60's, and, with a few improvements, would still be viable today (OO 
>>> and a concrete distinction between boolean and short-circuit operators, 
>>> at present left to the vagaries of the compiler's optimizing pass, would 
>>> be a start).
>>
>>
>> Could you explain what you mean by that?
>
> This *is* a potential problem.  The incorrect, but nearly universal, usage 
> is something like: "IF p^=NULL & p->whatever=...", which obviously depends 
> on the IF-statement evaluation being short-circuited before evaluating the 
> second condition if p is NULL.  [for the record, I now try to avoid this 
> by saying "IF p^=NULL THEN IF...".  The boolean version of this is "b = 
> (p^=NULL) & (p->whatever)...  I have put in logic to short-circuit the 
> evaluation in the first case, but not in the second.  Without checking, 
> I'd have to believe offhand that the standard is no short-circuiting in 
> all cases.  This should be defined explicitly, even if only in the terms 
> above.
>
>>>
>>> But PL/I is no longer a serious rival to Ada, its closest parallel. It 
>>> has had few significant upgrades since it was first introduced 40 years 
>>> ago, and it not likely to seriously upgraded now.
>>
>>
>> Not sure what you mean by that statement, is that a technical analysis?
>> Ada is a dead language from a market acceptance point of view.  You might
>> claim the same for PL/I; however, I would venture to guess that the 
>> number
>> of lines of code of PL/I to Ada in production is likely 100000:1 if not
>> more.
>
> From limited knowledge I'd thing Ada is more of a niche language than 
> PL/I, being largely (AFAIK) confined to defense and similar markets. PL/I 
> has more breath (sp?) of use  but probably not much more depth.
> I'd like to see this change in the future.  PL/I is superior to C 
> (probably no argument here), and could surpass C++ with a few additions, 
> as Peter's paper shows.  Now that hardware is no longer too limited to 
> support PL/I effectively, I'd like to see it move in on C, due to its 
> obvious superiority.
> 


0
1/2/2006 11:41:13 AM
multicsfan wrote:
> It is unlikely at this time that the Multics PL/1 compiler or Multics 
> system will ever be released.  Honeywell or Bull or whoever owns the 
> rights has been unwilling to release anything.  

Things are in limbo right now, but Tom Van V. (Multicians.org) is 
working with people inside Bull to try to make this happen.  I wouldn't 
hold your breath, but I expect it eventually.

> 
> One of the options I've always thought PL/1 should have is an 
> options(binary) to tell the compiler to assume all constants can be 
> converted to binary from to match the operand they are being used with. 
>  This avoids the inexperienced PL/1 scientific programmer from getting 
> bit by using decimal constants.
> 

Why would you need this?  I would expect the compiler to convert 
constants to the appropriate format at compile-time, using the 
appropriate language rules.

0
Peter_Flass (956)
1/2/2006 12:49:30 PM
robin wrote:

> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
> news:l7Rtf.69073$ME5.15991@twister.nyroc.rr.com...
> 
>>You have said this before, and I have been considxering your thoughts
>>before adding my $.02 (d@mn PeeCee keyboards don't have a "cent" sign.)
> 
> 
> You mean 2� ?
> 

Yes, how did you do it?  Enter the hex code?

0
Peter_Flass (956)
1/2/2006 12:50:12 PM
On Mon, 02 Jan 2006 13:21:41 GMT, multicsfan <multicsfan@hotmail.com>  
wrote:

> The best way is to always declare constants like dcl three float bin  
> init(3)

static;

0
tom284 (1839)
1/2/2006 1:15:56 PM

Peter Flass wrote:
> multicsfan wrote:
> 
>> It is unlikely at this time that the Multics PL/1 compiler or Multics 
>> system will ever be released.  Honeywell or Bull or whoever owns the 
>> rights has been unwilling to release anything.  
> 
> 
> Things are in limbo right now, but Tom Van V. (Multicians.org) is 
> working with people inside Bull to try to make this happen.  I wouldn't 
> hold your breath, but I expect it eventually.

I know, I'm not holding my breath.  There is a multicians yahoo group.

>> One of the options I've always thought PL/1 should have is an 
>> options(binary) to tell the compiler to assume all constants can be 
>> converted to binary from to match the operand they are being used 
>> with.  This avoids the inexperienced PL/1 scientific programmer from 
>> getting bit by using decimal constants.
>>
> 
> Why would you need this?  I would expect the compiler to convert 
> constants to the appropriate format at compile-time, using the 
> appropriate language rules.

The use is to get around the problem that is you have something like:

dcl a float bin;

a=3*4+2;  /* IIRC this gives an answer of 4 in PL/1-F and other compilers */

all the number oare considerd fixed decimal (1,0) compile time so all 
the math is done as fixed decimal (1,0) until the assignment is reached 
at which point the fixed decimal(1,0) number is converted to float bin.

with the binary option, the constants are stored as fixed bin and the 
result ends up being the expected answer of 14.

The best way is to always declare constants like dcl three float bin 
init(3);
0
multicsfan (63)
1/2/2006 1:21:41 PM
I had warp 4.  It would not load and run properly on the pc I had at the 
time.  I also could not justify having a second computer just to have 
PL/1 that could not generate code to run under windows.  I ended up 
using borland turbo C++ and did the minimum programming I needed.

robin wrote:

> "multicsfan" <multicsfan@hotmail.com> wrote in message
> news:xjVtf.5646$gq4.393@trndny04...
> 
>>The first one I was able to afford was the IBM Personal which
>>at that time was OS/2 only and I could not get OS/2 to load on my computer.
> 
> 
> Perseverence.  OS/2 will load on a PC.
> You can probably still get Warp 4, or maybe even Warp 3.
> Maybe even Ver 2.
> 
> 
0
multicsfan (63)
1/2/2006 1:23:56 PM
When I took most of my actual programming type classes in college the 
instructor taught structured programming and would insist on GOTO-less 
programming so I got into the habit of avoiding GOTO's unless absolutly 
necessary.  Yes your solution is shorter but has an evil goto in it ;);)

robin wrote:

> "multicsfan" <multicsfan@hotmail.com> wrote in message
> news:ODVtf.2746$tJ1.1354@trndny01...
> 
>>I seem to remember doing (its been about 25 years)
>>
>>eof=1b;
>>on endfile(X) eof=0b;
>>read file(X);
>>do while(eof);
>>   process record;
>>   read file(X);
>>   end;
>>
>>I know tehre is an extra read, but this worked better in the PL/1
>>compiler I used.  At that time there was no UNTIL in the compiler I was
>>using.
> 
> 
> The following needs only one read:-
> 
> on endfile (x) go to complete;
> do forever;
>    read file (x) into (d);
>    <<process record>>
> end;
> complete:
> 
> 
0
multicsfan (63)
1/2/2006 1:33:06 PM
Peter Flass wrote:
> robin wrote:
> 
>> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
>> news:l7Rtf.69073$ME5.15991@twister.nyroc.rr.com...
>>
>>> You have said this before, and I have been considxering your thoughts
>>> before adding my $.02 (d@mn PeeCee keyboards don't have a "cent" sign.)
>>
>>
>>
>> You mean 2� ?
>>
> 
> Yes, how did you do it?  Enter the hex code?
> 
Under Windows XP, try

start > All Programs > Accessories > System Tools > Character Map

That brings up a window with all sorts of characters in all sorts of 
fonts.  Highlight the characters you want, one at a time, and click on 
"Select".  That will build up a character string in "Characters to 
copy".  When you have the character(s) you want in "Characters to copy", 
click on "Copy".  Then go to the place in text where you want to insert 
the character(s) and right-click to paste them in.


Bob Lidral
lidral  at  alum  dot  mit  dot edu
0
1/2/2006 2:50:28 PM
multicsfan wrote:
> 
> 
> Peter Flass wrote:
>> Tom Linden wrote:
> [snip]
> 
>>  From limited knowledge I'd thing Ada is more of a niche language than 
>> PL/I, being largely (AFAIK) confined to defense and similar markets. 
>> PL/I has more breath (sp?) of use  but probably not much more depth.
>> I'd like to see this change in the future.  PL/I is superior to C 
>> (probably no argument here), and could surpass C++ with a few 
>> additions, as Peter's paper shows.  Now that hardware is no longer too 
>> limited to support PL/I effectively, I'd like to see it move in on C, 
>> due to its obvious superiority.
> 
> The biggest reason C took over was C compilers were free or low cost 
> compared to PL/1.  Gcc is free and runs on just about everything.  I 
> looked at buying a PL/1 compiler several times, but each time I was able 
> to afford to pay more, the price went up just outside what I was willing 
> to pay.  The first one I was able to afford was the IBM Personal which 
> at that time was OS/2 only and I could not get OS/2 to load on my computer.

C also has the advantage of being married to the Unix architecture, and 
almost every operating system around today (yes, even Windows, to the 
extent that it can be) is based on that architecture.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/2/2006 3:40:57 PM
multicsfan wrote:
> The use is to get around the problem that is you have something like:
> 
> dcl a float bin;
> 
> a=3*4+2;  /* IIRC this gives an answer of 4 in PL/1-F and other 
> compilers */
> 
> all the number oare considerd fixed decimal (1,0) compile time so all 
> the math is done as fixed decimal (1,0) until the assignment is reached 
> at which point the fixed decimal(1,0) number is converted to float bin.

Not in any dialect of PL/I I'm familiar with. If MULTICS PL/I does that, 
it's a huge mistake. PL/I does have problems in this area, especially 
when fixed-point division is involved, but it isn't supposed to do that.

The usual decimal/binary failure is caused by not fully declaring ENTRY 
attributes.

CALL DOIT (2);
....

DOIT: PROCEDURE (X);
   DECLARE X FLOAT;
   ...

fails, but

DECLARE DOIT ENTRY (FLOAT);
....
CALL DOIT (2);
....

DOIT: PROCEDURE (X);
   DECLARE X FLOAT;
   ...

works.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/2/2006 3:47:01 PM
Tom Linden wrote:
> On Sun, 01 Jan 2006 11:45:00 -0500, John W. Kennedy 
> <jwkenne@attglobal.net> wrote:
> 
>> The language is in limbo as to whether the following will crash when x 
>> is zero:
>>    if x ^= 0 & y/x < 10 then ...
>>
> No limbo ther, it should crash.  The correct (safe) way to code this is
> 
> if x ^= 0 then if  y/x < 10 then
> 
> or with our compiler
> 
> 
> if x ^= 0 &: y/x < 10 then

Unfortunately, for /decades/, some compilers have compiled the & to a 
short-circuit as a side-effect of optimization, and even documented the 
practice as normal.

I entirely agree that your compiler gets it right -- but "&:" is not an 
official part of the language.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/2/2006 3:51:15 PM
robin wrote:
> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> news:jGTtf.13706$L75.10549@fe12.lga...
> 
>> The language is in limbo as to whether the following will crash when x
>> is zero:
>>
>>    if x ^= 0 & y/x < 10 then ...
> 
> That is a programming error.  Why do you expect that it will not crash
> when x is zero?

Because the PL/I Optimizing Compiler and, I think, the new compiler as 
well, will not crash, and document that fact.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/2/2006 3:53:07 PM
adaworks@sbcglobal.net wrote:
> My concern, with regard to PL/I, is whether it has continued to evolve in a way
> that
> it remains competitive, in features and capabilities, with newer languages. 

Individual compilers have seen some proprietary improvements, but 
de-jure standard PL/I is archaic and unlikely every to be updated, and 
there is no longer any de-facto standard.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/2/2006 3:59:38 PM
Peter Flass wrote:
> John W. Kennedy wrote:
> John - your example is a bit *too* simple, since it just raises the 
> ERROR condition.

I don't have access to a compiler, but I don't offhand see any reason 
that it should fail. Have you actually tried it (wrapped in a MAIN, of 
course)?

> I think I see where you're going on this, but as I 
> said, you can model the exception-handling of (I believe) *any* other 
> language in PL/I.  Sure, you get lots of rope to hang yourself with 
> nonsensical code, but the language only provides the tools.  How you use 
> or misuse them is your own business.
> 
> A better example might be:
>   sample: PROC(x);
>     SELECT(x);
>       WHEN(1) DO;
>         ON CONDITION(foo) PUT DATA;
>         END;
>        WHEN(2) DO;
>          ON CONDITION(foo) DO;
>            PUT SKIP LIST( 'foo condition raised' );
>            END;
>        WHEN(3) DO;
>           <some other action to be taken for foo>
>           END
>         END; /* select */
>     <do sone stuff>
>     IF <whatever> THEN SIGNAL CONDITION(foo);
>     END sample;

I'm afraid that doesn't have any bearing on my point at all. (By the 
way, on all dialects that I know, ON...DO is forbidden; it has to be 
ON...BEGIN.)

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/2/2006 4:07:43 PM
robin wrote:
> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> news:qdUtf.6827$2j2.3540@fe11.lga...
>> Tom Linden wrote:
>>> Setjmp and longjmp are primitive copies of the PL/I signalling mechanisms
>>> and lack semantic analysis.
>> I doubt that PL/I had much to do with it. PL/I was the first HLL to
>> implement exception handling -- but the concept already existed at the
>> assembler-language level.
> 
> Which hardware prior to S/360 offered exception handling?

The 7030, for one.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/2/2006 4:13:13 PM
Peter Flass wrote:
> robin wrote:
>>
>> There may not be much difference between ENDFILE condition and
>> function in this particular case, but the function is impractical
>> for stream input, having to test for end-of-file after each element is 
>> input.
>>  
> Interesting point, which I hadn't considered.  You could awlays do it 
> the C way: return as much data as you got, have the ENDFILE builtin 
> return true, and let the programmer sort out what he's got.

The issue is not whether ON ENDFILE is /ever/ of any use, but whether it 
was the right design for universal use. (And the proposed case is 
sloppy, anyway. Allocate a bigger-than-necessary array -- which also 
requires the programmer to impose an arbitrary upper limit -- and then 
either be stuck with that larger-than-necessary array -- pure 1950's 
FORTRAN thinking -- or else create a second, smaller array and copy it. 
Ugh!)

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/2/2006 4:18:46 PM
"multicsfan" <multicsfan@hotmail.com> wrote in message 
news:mY9uf.2643$Z74.990@trndny06...
> When I took most of my actual programming type classes in college the 
> instructor taught structured programming and would insist on GOTO-less 
> programming so I got into the habit of avoiding GOTO's unless absolutly 
> necessary.  Yes your solution is shorter but has an evil goto in it ;);)
>
> robin wrote:

Welcome to the real world outside the Ivory Tower of Academia!
I've been programming since the mid-60's and when new people show up at work
fresh out of school, they see my work and practically have a coronary.  I 
break 'em
in real fast.  Some of them don't even know there are programming languages 
other
than C or C++ or think that those are the only "real" programming languages.
Book learning is fine but I'd hire people with real-world experience any 
day.

Tom "Gramps" Lake 


0
tlake (477)
1/2/2006 5:49:29 PM
On Mon, 02 Jan 2006 10:47:01 -0500, John W. Kennedy  
<jwkenne@attglobal.net> wrote:

> multicsfan wrote:
>> The use is to get around the problem that is you have something like:
>>  dcl a float bin;
>>  a=3*4+2;  /* IIRC this gives an answer of 4 in PL/1-F and other  
>> compilers */
>>  all the number oare considerd fixed decimal (1,0) compile time so all  
>> the math is done as fixed decimal (1,0) until the assignment is reached  
>> at which point the fixed decimal(1,0) number is converted to float bin.
>
> Not in any dialect of PL/I I'm familiar with. If MULTICS PL/I does that,  
> it's a huge mistake. PL/I does have problems in this area, especially  
> when fixed-point division is involved, but it isn't supposed to do that.
>
> The usual decimal/binary failure is caused by not fully declaring ENTRY  
> attributes.
>
> CALL DOIT (2);
> ...
>
> DOIT: PROCEDURE (X);
>    DECLARE X FLOAT;
>    ...
>
> fails, but
>
> DECLARE DOIT ENTRY (FLOAT);
> ...
> CALL DOIT (2);
> ...
>
> DOIT: PROCEDURE (X);
>    DECLARE X FLOAT;
>    ...
>
> works.
>

On VMS  this is what you get
FREJA> create fb.pli
t: proc options(main);
dcl a float bin;
a = 3*4+2;
put skip list(a);
end;
*EXIT*
FREJA> pli fb
FREJA> link fb
FREJA> run fb

  1.4000000E+01

And this is in accordance with the ansi rules for maintaining
intermediate precision
0
tom284 (1839)
1/2/2006 5:56:28 PM
On Mon, 02 Jan 2006 10:40:57 -0500, John W. Kennedy  
<jwkenne@attglobal.net> wrote:

> C also has the advantage of being married to the Unix architecture, and  
> almost every operating system around today (yes, even Windows, to the  
> extent that it can be) is based on that architecture.
>
Actually, Windows is probably a lot closer to VMS than to Unix, after all,
they both had the same chief architect; however, in Windows they forgot
about the security model and they didn't use dope vectors.
0
tom284 (1839)
1/2/2006 5:58:57 PM
On Mon, 02 Jan 2006 10:51:15 -0500, John W. Kennedy  
<jwkenne@attglobal.net> wrote:

> I entirely agree that your compiler gets it right -- but "&:" is not an  
> official part of the language.
>
Well it is in the refernce manual.  Maybe IBM should add it to make it
official:-)  As i recall it added two levels to the expression parser
(from 7 to 9) for precedence and was pretty trivial to implement.
0
tom284 (1839)
1/2/2006 6:02:49 PM
On Mon, 02 Jan 2006 10:53:07 -0500, John W. Kennedy  
<jwkenne@attglobal.net> wrote:

> robin wrote:
>> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
>> news:jGTtf.13706$L75.10549@fe12.lga...
>>
>>> The language is in limbo as to whether the following will crash when x
>>> is zero:
>>>
>>>    if x ^= 0 & y/x < 10 then ...
>>  That is a programming error.  Why do you expect that it will not crash
>> when x is zero?
>
> Because the PL/I Optimizing Compiler and, I think, the new compiler as  
> well, will not crash, and document that fact.
>
It should cause an exception and cause the program to abort.  I think you
meant the compiled program, not the compiler crashing

0
tom284 (1839)
1/2/2006 6:05:07 PM
On Mon, 02 Jan 2006 17:49:29 GMT, Tom Lake <tlake@twcny.rr.com> wrote:

> "multicsfan" <multicsfan@hotmail.com> wrote in message
> news:mY9uf.2643$Z74.990@trndny06...
>> When I took most of my actual programming type classes in college the
>> instructor taught structured programming and would insist on GOTO-less
>> programming so I got into the habit of avoiding GOTO's unless absolutly
>> necessary.  Yes your solution is shorter but has an evil goto in it ;);)
>>
>> robin wrote:
>
> Welcome to the real world outside the Ivory Tower of Academia!
> I've been programming since the mid-60's and when new people show up at  
> work
> fresh out of school, they see my work and practically have a coronary.  I
> break 'em
> in real fast.  Some of them don't even know there are programming  
> languages
> other
> than C or C++ or think that those are the only "real" programming  
> languages.
> Book learning is fine but I'd hire people with real-world experience any
> day.
>
> Tom "Gramps" Lake
>
>
I like structured GOTO's
0
tom284 (1839)
1/2/2006 6:12:21 PM
multicsfan wrote:
>>> One of the options I've always thought PL/1 should have is an 
>>> options(binary) to tell the compiler to assume all constants can be 
>>> converted to binary from to match the operand they are being used 
>>> with.  This avoids the inexperienced PL/1 scientific programmer from 
>>> getting bit by using decimal constants.
>>>
>>
>> Why would you need this?  I would expect the compiler to convert 
>> constants to the appropriate format at compile-time, using the 
>> appropriate language rules.
> 
> 
> The use is to get around the problem that is you have something like:
> 
> dcl a float bin;
> 
> a=3*4+2;  /* IIRC this gives an answer of 4 in PL/1-F and other 
> compilers */
> 
> all the number oare considerd fixed decimal (1,0) compile time so all 
> the math is done as fixed decimal (1,0) until the assignment is reached 
> at which point the fixed decimal(1,0) number is converted to float bin.
> 

I see where you're going with this, but binary or decimal, the results 
should be the same.  This is a bad example, you need a division instead 
of multiplication to potentially cause a problem, but what you want is 
to evaluate this as FLOAT rather than FIXED, something like: a = 
float(3)*4+2

I don't have a manual handy that has the nice table, but for the F compiler:
    multiplication:         p = p1 + p2 + 1
                            q = q1 + q2
    addition/subtraction:   p = 1 + max( p1-q1, p2-q2 ) + max( q1, q2 )
                            q = max( q1, q2 )
You're right, all your constants are FIXED DECIMAL(1,0)
   3*4 gives a FIXED DEC(3,0) result
   (3*4)+2 gives a FIXED DEC(4,0) result
So the FIXED DEC(4,0) value '14' will be correctly assigned to a.

Division can give strange results, but for FIXED division, PL/I attempts 
to retain the largest possible number of fractional digits in the result 
after allowing enough integer digits:
     p = M
     q = M - ( ( p1 - q1 ) + q2 )
where M is the maximum possible number of digits for the radix used.



> with the binary option, the constants are stored as fixed bin and the 
> result ends up being the expected answer of 14.
> 
> The best way is to always declare constants like dcl three float bin 
> init(3);

0
Peter_Flass (956)
1/2/2006 7:50:49 PM
John W. Kennedy wrote:

> Peter Flass wrote:
> 
>> John W. Kennedy wrote:
>> John - your example is a bit *too* simple, since it just raises the 
>> ERROR condition.
> 
> 
> I don't have access to a compiler, but I don't offhand see any reason 
> that it should fail. Have you actually tried it (wrapped in a MAIN, of 
> course)?
> 

Oops, sorry, I was not seeing the OTHERWISE, whose absence would cause 
ERROR on CALL sample(0).  I can't see any unpredictability, it's just 
hard to read.  It should give you a endless loop, printing "x=1;" "x=1;" 
"x=2;" ...  if I read it right.  This is just another example of how 
recursion can bite you in the @ss

0
Peter_Flass (956)
1/2/2006 8:04:52 PM
Tom Linden wrote:
> On Mon, 02 Jan 2006 10:53:07 -0500, John W. Kennedy 
> <jwkenne@attglobal.net> wrote:
> 
>> robin wrote:
>>> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
>>> news:jGTtf.13706$L75.10549@fe12.lga...
>>>
>>>> The language is in limbo as to whether the following will crash when x
>>>> is zero:
>>>>
>>>>    if x ^= 0 & y/x < 10 then ...
>>>  That is a programming error.  Why do you expect that it will not crash
>>> when x is zero?
>>
>> Because the PL/I Optimizing Compiler and, I think, the new compiler as 
>> well, will not crash, and document that fact.
>>
> It should cause an exception and cause the program to abort.  I think you
> meant the compiled program, not the compiler crashing

Yes, I assumed the ellipsis would be filled in. As I say elsewhere, the 
short-circuiting is a side-effect of optimization, but is unfortunately 
documented in such a way as to appear to be the defined semantics.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/2/2006 11:11:01 PM
Peter Flass wrote:
> John W. Kennedy wrote:
> 
>> Peter Flass wrote:
>>
>>> John W. Kennedy wrote:
>>> John - your example is a bit *too* simple, since it just raises the 
>>> ERROR condition.
>>
>>
>> I don't have access to a compiler, but I don't offhand see any reason 
>> that it should fail. Have you actually tried it (wrapped in a MAIN, of 
>> course)?
>>
> 
> Oops, sorry, I was not seeing the OTHERWISE, whose absence would cause 
> ERROR on CALL sample(0).  I can't see any unpredictability, it's just 
> hard to read.  It should give you a endless loop, printing "x=1;" "x=1;" 
> "x=2;" ...  if I read it right.  This is just another example of how 
> recursion can bite you in the @ss

No, the WHEN (5) breaks the recursion.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/2/2006 11:16:35 PM
On Mon, 02 Jan 2006 18:11:01 -0500, John W. Kennedy  
<jwkenne@attglobal.net> wrote:

> Yes, I assumed the ellipsis would be filled in. As I say elsewhere, the  
> short-circuiting is a side-effect of optimization, but is unfortunately  
> documented in such a way as to appear to be the defined semantics.
>
I had in for many years as an option in optimization, but in the end, I
took it out, because it is wrong.
0
tom284 (1839)
1/2/2006 11:20:52 PM
Tom Lake wrote:
> "multicsfan" <multicsfan@hotmail.com> wrote in message 
> news:mY9uf.2643$Z74.990@trndny06...
>> When I took most of my actual programming type classes in college the 
>> instructor taught structured programming and would insist on GOTO-less 
>> programming so I got into the habit of avoiding GOTO's unless absolutly 
>> necessary.  Yes your solution is shorter but has an evil goto in it ;);)
>>
>> robin wrote:
> 
> Welcome to the real world outside the Ivory Tower of Academia!
> I've been programming since the mid-60's and when new people show up at work
> fresh out of school, they see my work and practically have a coronary.  I 
> break 'em
> in real fast.  Some of them don't even know there are programming languages 
> other
> than C or C++ or think that those are the only "real" programming languages.
> Book learning is fine but I'd hire people with real-world experience any 
> day.
> 

Actually, as a matter of real-world experience with PL/I, I was 
consciously avoiding GOTO as much as possible before Dijkstra published. 
(Because the D compiler only permitted ON ... GOTO, I could not avoid it 
altogether.)

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/2/2006 11:22:38 PM
On Tue, 03 Jan 2006 00:26:32 GMT, robin <robin_v@bigpond.com> wrote:

> "multicsfan" <multicsfan@hotmail.com> wrote in message
> news:60%tf.1342$494.168@trndny07...
>> It is unlikely at this time that the Multics PL/1 compiler or Multics
>> system will ever be released.  Honeywell or Bull or whoever owns the
>> rights has been unwilling to release anything.  The only code that has
>> been 'released' is a very old version developed with government funds
>> around MR4/MR5 IIRC.  The latest MR12 is basically in limbo.
>
> Then perhaps a better bet would be to try to get the source for
> Cornell University's PL/I aka PL/C.
>
Actually, I licensed ny compiler to Bull around Dec 1987, for the Multics  
(?)
replacement machine, which was abruptly cancelled three months later.

0
tom284 (1839)
1/3/2006 12:22:17 AM
"multicsfan" <multicsfan@hotmail.com> wrote in message
news:60%tf.1342$494.168@trndny07...
> It is unlikely at this time that the Multics PL/1 compiler or Multics
> system will ever be released.  Honeywell or Bull or whoever owns the
> rights has been unwilling to release anything.  The only code that has
> been 'released' is a very old version developed with government funds
> around MR4/MR5 IIRC.  The latest MR12 is basically in limbo.

Then perhaps a better bet would be to try to get the source for
Cornell University's PL/I aka PL/C.


0
robin_v (2737)
1/3/2006 12:26:32 AM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:Oc_tf.63839$XC4.25408@twister.nyroc.rr.com...
> robin wrote:
> >
> > There may not be much difference between ENDFILE condition and
> > function in this particular case, but the function is impractical
> > for stream input, having to test for end-of-file after each element is
input.
> >
> Interesting point, which I hadn't considered.  You could awlays do it
> the C way: return as much data as you got, have the ENDFILE builtin
> return true, and let the programmer sort out what he's got.

That isn't a great way to do it.  There's always the possibility that
the user doesn't include a test for end of file, in which case the
program carries on without warning with non-valid data.
    It's better that the run time system makes a loud noise, which
is what PL/I currently does when the user omits an error handler
for ENDFILE (and come to think of it, also what PL/I does for
ZERODIVIDE and all the other hardware exceptions).


0
robin_v (2737)
1/3/2006 12:26:33 AM
<adaworks@sbcglobal.net> wrote in message
news:L5Wtf.44007$q%.25047@newssvr12.news.prodigy.com...
>
> "Tom Linden" <tom@kednos.com> wrote in message
> news:ops2olvrjtzgicya@hyrrokkin...
> The European Space Agency is a big user.   We continue to develop military
> software in Ada.   It has widespread use in transportation systems such as
> railway switching and control.   And it is used for communication satellites,
> and other space applications.   It is not used much by those programming
> desktop systems, and seems also true of PL/I.

PL/I is used on desktop systems, and a variety of compilers
is provided by different vendors.  IBM in particular have
produced its Windows version for program development
to be compatible, when required, with its mainframes.


0
robin_v (2737)
1/3/2006 12:26:33 AM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:wLZtf.63670$XC4.33597@twister.nyroc.rr.com...
> If I understand your C or Ada correctly, the language doesn't imply, but
> specifies this.  Reflecting further on the standard, I believe
> conditionals are supposed to be completely evaluated to return a BIT(1)
> result (boolean) which is then tested.
>
> 'IF a=b AND c=d' is supposed to evaluate both conditions and then AND
> the result bits.

Since there are no function references in the two comparisons,
for a single processor there's no reason why the comparison a=b
yielding false should not terminate evaluation, thus avoiding
evaluating the'&'.
    However, for multiple processors, that's not possible,
given that one comparison could be evaluated on one processor
and the other comparison evaluated on the other.

>  I understand why short-circuiting was instituted, but
> it "really" isn't correct.


0
robin_v (2737)
1/3/2006 12:26:34 AM
"multicsfan" <multicsfan@hotmail.com> wrote in message
news:FN9uf.3590$i%4.1508@trndny08...
>
> Peter Flass wrote:
> > multicsfan wrote:
> >
> >> It is unlikely at this time that the Multics PL/1 compiler or Multics
> >> system will ever be released.  Honeywell or Bull or whoever owns the
> >> rights has been unwilling to release anything.
> >
> > Things are in limbo right now, but Tom Van V. (Multicians.org) is
> > working with people inside Bull to try to make this happen.  I wouldn't
> > hold your breath, but I expect it eventually.
>
> I know, I'm not holding my breath.  There is a multicians yahoo group.
>
> >> One of the options I've always thought PL/1 should have is an
> >> options(binary) to tell the compiler to assume all constants can be
> >> converted to binary from to match the operand they are being used
> >> with.  This avoids the inexperienced PL/1 scientific programmer from
> >> getting bit by using decimal constants.
> >>
> > Why would you need this?  I would expect the compiler to convert
> > constants to the appropriate format at compile-time, using the
> > appropriate language rules.
>
> The use is to get around the problem that is you have something like:
>
> dcl a float bin;
>
> a=3*4+2;  /* IIRC this gives an answer of 4 in PL/1-F and other compilers */

No PL/I compiler ever did that, and especially not IBM's F compiler.

> all the number oare considerd fixed decimal (1,0) compile time so all
> the math is done as fixed decimal (1,0)

No it isn't.  The product of the constants 3 and 4 produces a result
of precision (3,0), and adding the procuct to 4 gives precision (4,0).
The result is +0014 (precision (4,0).

> until the assignment is reached
> at which point the fixed decimal(1,0) number is converted to float bin.

No, you are quite wrong.  The working is shown as above.
The result +0014 is converted to float, and assigned.
(An optimiser might convert the decimal to float at compile time.)

> with the binary option, the constants are stored as fixed bin and the
> result ends up being the expected answer of 14.

The binary option wouldn't change anything.

> The best way is to always declare constants like dcl three float bin
> init(3);

The best way to use a constant is usually "as is".  "3" is absolutely clear
and means exactly 3.


0
robin_v (2737)
1/3/2006 1:56:12 AM
As I said, I don't remember teh exact example anymore, it was 30+ years 
ago and as I stated was in IBM PL/1-F.

Peter Flass wrote:

> multicsfan wrote:
> 
>>>> One of the options I've always thought PL/1 should have is an 
>>>> options(binary) to tell the compiler to assume all constants can be 
>>>> converted to binary from to match the operand they are being used 
>>>> with.  This avoids the inexperienced PL/1 scientific programmer from 
>>>> getting bit by using decimal constants.
>>>>
>>>
>>> Why would you need this?  I would expect the compiler to convert 
>>> constants to the appropriate format at compile-time, using the 
>>> appropriate language rules.
>>
>>
>>
>> The use is to get around the problem that is you have something like:
>>
>> dcl a float bin;
>>
>> a=3*4+2;  /* IIRC this gives an answer of 4 in PL/1-F and other 
>> compilers */
>>
>> all the number oare considerd fixed decimal (1,0) compile time so all 
>> the math is done as fixed decimal (1,0) until the assignment is 
>> reached at which point the fixed decimal(1,0) number is converted to 
>> float bin.
>>
> 
> I see where you're going with this, but binary or decimal, the results 
> should be the same.  This is a bad example, you need a division instead 
> of multiplication to potentially cause a problem, but what you want is 
> to evaluate this as FLOAT rather than FIXED, something like: a = 
> float(3)*4+2
> 
> I don't have a manual handy that has the nice table, but for the F 
> compiler:
>    multiplication:         p = p1 + p2 + 1
>                            q = q1 + q2
>    addition/subtraction:   p = 1 + max( p1-q1, p2-q2 ) + max( q1, q2 )
>                            q = max( q1, q2 )
> You're right, all your constants are FIXED DECIMAL(1,0)
>   3*4 gives a FIXED DEC(3,0) result
>   (3*4)+2 gives a FIXED DEC(4,0) result
> So the FIXED DEC(4,0) value '14' will be correctly assigned to a.
> 
> Division can give strange results, but for FIXED division, PL/I attempts 
> to retain the largest possible number of fractional digits in the result 
> after allowing enough integer digits:
>     p = M
>     q = M - ( ( p1 - q1 ) + q2 )
> where M is the maximum possible number of digits for the radix used.
> 
> 
> 
>> with the binary option, the constants are stored as fixed bin and the 
>> result ends up being the expected answer of 14.
>>
>> The best way is to always declare constants like dcl three float bin 
>> init(3);
> 
> 
0
multicsfan (63)
1/3/2006 3:26:10 AM
I've thought about that.  when I was an undergrad the choices ofPL/1 on 
the IBM mainframe were either IBM PL/1-F or PL/C.  PL/C's ability to 
'correct' syntax errors was pretty amazing.  One of my friends feed his 
algol project (large program) to PL/C and it actually produced the 
correct result thought it did average better then 4 warning messages per 
line of algol ;)

robin wrote:

> "multicsfan" <multicsfan@hotmail.com> wrote in message
> news:60%tf.1342$494.168@trndny07...
> 
>>It is unlikely at this time that the Multics PL/1 compiler or Multics
>>system will ever be released.  Honeywell or Bull or whoever owns the
>>rights has been unwilling to release anything.  The only code that has
>>been 'released' is a very old version developed with government funds
>>around MR4/MR5 IIRC.  The latest MR12 is basically in limbo.
> 
> 
> Then perhaps a better bet would be to try to get the source for
> Cornell University's PL/I aka PL/C.
> 
> 
0
multicsfan (63)
1/3/2006 3:30:05 AM
The Multics replacement machine project was called Flower.  There are 
more details at the Multics site http://www.multicians.org/


Tom Linden wrote:

> On Tue, 03 Jan 2006 00:26:32 GMT, robin <robin_v@bigpond.com> wrote:
> 
>> "multicsfan" <multicsfan@hotmail.com> wrote in message
>> news:60%tf.1342$494.168@trndny07...
>>
>>> It is unlikely at this time that the Multics PL/1 compiler or Multics
>>> system will ever be released.  Honeywell or Bull or whoever owns the
>>> rights has been unwilling to release anything.  The only code that has
>>> been 'released' is a very old version developed with government funds
>>> around MR4/MR5 IIRC.  The latest MR12 is basically in limbo.
>>
>>
>> Then perhaps a better bet would be to try to get the source for
>> Cornell University's PL/I aka PL/C.
>>
> Actually, I licensed ny compiler to Bull around Dec 1987, for the 
> Multics  (?)
> replacement machine, which was abruptly cancelled three months later.
> 
0
multicsfan (63)
1/3/2006 3:34:04 AM
I started programming in the late 60's before i went off to college.  My 
first degree, BS Computer & Systems Engr from RPI was awarded in 1976 so 
I have a few years experience ;)

I do prefer structured programming, but I only consider GOTO's evil when 
abused or over used.

Tom Lake wrote:

> "multicsfan" <multicsfan@hotmail.com> wrote in message 
> news:mY9uf.2643$Z74.990@trndny06...
> 
>>When I took most of my actual programming type classes in college the 
>>instructor taught structured programming and would insist on GOTO-less 
>>programming so I got into the habit of avoiding GOTO's unless absolutly 
>>necessary.  Yes your solution is shorter but has an evil goto in it ;);)
>>
>>robin wrote:
> 
> 
> Welcome to the real world outside the Ivory Tower of Academia!
> I've been programming since the mid-60's and when new people show up at work
> fresh out of school, they see my work and practically have a coronary.  I 
> break 'em
> in real fast.  Some of them don't even know there are programming languages 
> other
> than C or C++ or think that those are the only "real" programming languages.
> Book learning is fine but I'd hire people with real-world experience any 
> day.
> 
> Tom "Gramps" Lake 
> 
> 
0
multicsfan (63)
1/3/2006 3:41:20 AM
Peter Flass wrote:
(snip)

>> all the number oare considerd fixed decimal (1,0) compile time so all 
>> the math is done as fixed decimal (1,0) until the assignment is 
>> reached at which point the fixed decimal(1,0) number is converted to 
>> float bin.

> I see where you're going with this, but binary or decimal, the results 
> should be the same.  This is a bad example, you need a division instead 
> of multiplication to potentially cause a problem, but what you want is 
> to evaluate this as FLOAT rather than FIXED, something like: a = 
> float(3)*4+2

The indicated problem comes when fixed point hits the limit in the
number of digits.

> I don't have a manual handy that has the nice table, but for the F 
> compiler:
>    multiplication:         p = p1 + p2 + 1
>                            q = q1 + q2
>    addition/subtraction:   p = 1 + max( p1-q1, p2-q2 ) + max( q1, q2 )
>                            q = max( q1, q2 )
> You're right, all your constants are FIXED DECIMAL(1,0)
>   3*4 gives a FIXED DEC(3,0) result
>   (3*4)+2 gives a FIXED DEC(4,0) result
> So the FIXED DEC(4,0) value '14' will be correctly assigned to a.

In addition, there is a limit on p...

> Division can give strange results, but for FIXED division, PL/I attempts 
> to retain the largest possible number of fractional digits in the result 
> after allowing enough integer digits:
>     p = M
>     q = M - ( ( p1 - q1 ) + q2 )
> where M is the maximum possible number of digits for the radix used.

The old favorite example, 25+1/3 which is 5.33333333333333  (some number 
of 3's).   The same result should occur from 25+0.33333333333333 with
no division, but it is much easier to do with division.

Both multiply and divide can easily generate more digits than either 
operand.  With a maximum number of digits, there is no all around right 
answer.

-- glen

0
gah (12851)
1/3/2006 4:26:26 AM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:fQbuf.6955$2j2.893@fe11.lga...
>
> C also has the advantage of being married to the Unix architecture, and
> almost every operating system around today (yes, even Windows, to the
> extent that it can be) is based on that architecture.
>
This Quarter, I will be teaching an operating systems principles class.  We will
use Minix as the operating system that students modify and write programs to
do experiments.  It is written in C.

C, while being inexpensive, is also relatively simple and compact.  Sometimes it
is called a "universal assembler."   There have been other attempts to design
such universal assemblers, but C endures.    It is really easy to learn.  One
does
not have to know much to get started.   Pointers are a problem, but one
eventually
gets the hang of them.  It is an error-prone language, and everyone learns the
importance of spending long hours debugging.

Someone made a comment about not having access to PL/I because it is
too expensive.   Ada originally had that problem since compiler publishers,
believing they had a captive audience in the DoD charge exorbitant prices
for compilers.  Now Ada compilers are availble for download, free.  Is
PL/I available in a free download form?   C is still one of the cheapest
alternatives
available for programming most platforms.

Large languages such as PL/I, Ada, C++, Eiffel, and others can require a student
to learn a lot before being productive.   At the same time, those large
languages
tend to be more reliable, have more built-in capabilities, and are typically
easier
to maintain.   Certainly, with the exception of C++, they result in more
readable
code.

Subsets of the larger languages (e.g., PL/M) have proven their worth on small
architectures, but C continues to dominate.  A professor at (I think this is
right)
University of South Carolina has a sign on his door, "C is its own virus."  I
have
a sign on the door of my university office, "C++ is its own virus."

The fact is that computer science students must learn C.  It is currently the
most
widely used systems programming language.   I dislike it for applications
programming, but it is, at present, a necessary evil in the  systems programming
world.

Richard Riehle


0
adaworks2 (748)
1/3/2006 6:20:02 AM
"Donald L. Dobbs" <donaldldobbs@cox.net> wrote in message
news:g1_tf.860$eR.655@fed1read03...
>
> Ada comes the closest to PL/I in this regard, but I find it's syntax
> abominable.  And, by the way, having spent most of my career in
> aerospace I have observed that there are far more applications being
> written in something else rather than in Ada including those products
> delivered to DoD.  (Boeing uses Ada, but as an insider I can tell you it
> was a major stuggle to ultimately achieve acceptable results -- some
> projects were delayed over a year because of it.)  Contemporary compiler
> implementations and better programmer training have overcome most of
> these initial difficulties.
>
A lot of people like Ada's syntax.  Also, the Ada 2005 standard adds
an option for distinguished receiver syntax.   Changing from one form
of language design to another is always painful and it is always easier
to write code in the new language as we did in our previous language.
Once we get past that hurdle, the new language seems natural and we
wonder why we had trouble with it in the first place.  I saw this happening
when a company I worked for decided to abandon COBOL in favor
of PL/I.  Everyone was upset at having to learn this "stupid new language,"
even though it eventually became clear that it had real advantages.

There is a slowly growing number of people choosing to use Ada for a
wide range of applications.  It is particularly useful on Linux.   There are
excellent libraries for programming Microsoft Windows as well as .NET.
It continues to be used for space applications.

When Ada was mandated by the DoD, there was a lot of resistance to
it. No one liked being told what language they had to use.  Now, with
the mandate rescinded, those who use it are doing so by choice.   The
freedom of choice makes it more successful because those who choose
it want to use it.

You are correct about the compiler implementations and training.  The
language was so different when it was first introduced that neither the
compiler writers nor the applications programmers understood what
they were dealing with.  Now, nearly every new language has adopted
some or much of what was originally unique to Ada.  Even Java now
has generics.   Also, Ada compilers and tools are far better than they
were originally.  However, the same can be said of almost any language:
COBOL, Fortran, PL/I, Ada, C++.  All had to get through some growing
pains before becoming as efficient as required and before having all the
tools for development we needed.   The new languages, Eiffel, Ruby,
Self, Java, and others are still going through some of that early pain. They
will catch up, eventually.

The developers of Ada learned a lot from the experience of PL/I.  Some
ideas they eschewed such as the complex exception handling model. Yet
from those ideas, they learned what approach to take.   Also, it is my
understanding that one of the very first Ada compilers was actually
written in PL/I.

Richard Riehle


0
adaworks2 (748)
1/3/2006 6:38:08 AM
adaworks@sbcglobal.net wrote:
(snip)

> Someone made a comment about not having access to PL/I because it is
> too expensive.   Ada originally had that problem since compiler publishers,
> believing they had a captive audience in the DoD charge exorbitant prices
> for compilers.  Now Ada compilers are availble for download, free.  Is
> PL/I available in a free download form? 

With a VMS hobbyist license, PL/I for VAX and Alpha is available free.

There is work on a GNU version, too.

 >  C is still one of the cheapest
> alternatives
> available for programming most platforms.
> 
> Large languages such as PL/I, Ada, C++, Eiffel, and others can require a student
> to learn a lot before being productive.   At the same time, those large
> languages
> tend to be more reliable, have more built-in capabilities, and are typically
> easier
> to maintain.   

Part of the design of PL/I is that one should not need to learn the 
whole language.  That is one reason for no reserved words.
I would guess the amount of PL/I needed to start writing useful programs
is smaller than the amount of C, but it is hard to say.

printf, and especially scanf, are not easy to learn to use compared to 
PUT LIST and GET LIST, with PUT EDIT somewhere in between.

-- glen

0
gah (12851)
1/3/2006 6:51:07 AM
"multicsfan" <multicsfan@hotmail.com> wrote in message
news:MP9uf.3591$i%4.2963@trndny08...
> I had warp 4.  It would not load and run properly on the pc I had at the
> time.

For some earlier computers, it was necessary to set the
memory wait time to the maximum.

> I also could not justify having a second computer just to have
> PL/1 that could not generate code to run under windows.

A separate computer was never needed.  OS/2 can run
as DUAL BOOT with DOS.  You either boot up OS/2 or
you boot up DOS+Windows -- any time you want.



0
robin_v (2737)
1/3/2006 3:14:58 PM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:8k9uf.71096$ME5.53192@twister.nyroc.rr.com...
> robin wrote:
> > "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
> > news:l7Rtf.69073$ME5.15991@twister.nyroc.rr.com...
> >
> >>You have said this before, and I have been considxering your thoughts
> >>before adding my $.02 (d@mn PeeCee keyboards don't have a "cent" sign.)
>
> > You mean 2� ?
>
> Yes, how did you do it?  Enter the hex code?

ALT-1-6-2


0
robin_v (2737)
1/3/2006 3:14:58 PM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:Hncuf.6969$2j2.1551@fe11.lga...

> The issue is not whether ON ENDFILE is /ever/ of any use, but whether it
> was the right design for universal use.

It is clearly the right design for general use.
It is required, at the very least, for stream input.
Works wonders with record input too.

 (And the proposed case is
> sloppy, anyway. Allocate a bigger-than-necessary array -- which also
> requires the programmer to impose an arbitrary upper limit -- and then
> either be stuck with that larger-than-necessary array -- pure 1950's
> FORTRAN thinking -- or else create a second, smaller array and copy it.
> Ugh!)

The relevance of this "bigger-than-necessary array" is?


0
robin_v (2737)
1/3/2006 3:14:59 PM
On Tue, 03 Jan 2006 06:20:02 GMT, <adaworks@sbcglobal.net> wrote:

> Large languages such as PL/I, Ada, C++, Eiffel, and others can require a  
> student
> to learn a lot before being productive.

You can actually write PL/I with very simple constructs, and you can make
it successively more sophisticated, and no better language for introducing  
the
student to things like templates, linked lists and so on.

Your cost, $0, priceless!  I'll give yo a free educational license
0
tom284 (1839)
1/3/2006 3:51:20 PM
On Tue, 03 Jan 2006 06:38:08 GMT, <adaworks@sbcglobal.net> wrote:

> The developers of Ada learned a lot from the experience of PL/I.  Some
> ideas they eschewed such as the complex exception handling model. Yet
> from those ideas, they learned what approach to take.   Also, it is my
> understanding that one of the very first Ada compilers was actually
> written in PL/I.

Digital asked me in 1982 if I would write an Ada compiler for the VAX, to
which I said yes, provided I didn't have to use Diana and that I could  
write
it PL/I.
0
tom284 (1839)
1/3/2006 3:54:43 PM
>> >>You have said this before, and I have been considxering your thoughts
>> >>before adding my $.02 (d@mn PeeCee keyboards don't have a "cent" sign.)
>>
>> > You mean 2� ?
>>
>> Yes, how did you do it?  Enter the hex code?
>
> ALT-1-6-2

That's a neat trick!

Just my 0.0167088 ?

Tom Lake



0
tlake (477)
1/3/2006 4:07:32 PM
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Part of the design of PL/I is that one should not need to learn the 
> whole language.  That is one reason for no reserved words.
> I would guess the amount of PL/I needed to start writing useful programs
> is smaller than the amount of C, but it is hard to say.
> 
> printf, and especially scanf, are not easy to learn to use compared to 
> PUT LIST and GET LIST, with PUT EDIT somewhere in between.

I had a highly experienced C developer state that inexperienced
programmers don't understand how to use scanf() while experienced
programmers know to not use it.
0
mojaveg595 (241)
1/3/2006 6:45:02 PM
The problem was I needed windows all the time for windows stuff for work 
realted stuff.  The PL/1 was entierly personal.

robin wrote:

> "multicsfan" <multicsfan@hotmail.com> wrote in message
> news:MP9uf.3591$i%4.2963@trndny08...
> 
>>I had warp 4.  It would not load and run properly on the pc I had at the
>>time.
> 
> 
> For some earlier computers, it was necessary to set the
> memory wait time to the maximum.
> 
> 
>>I also could not justify having a second computer just to have
>>PL/1 that could not generate code to run under windows.
> 
> 
> A separate computer was never needed.  OS/2 can run
> as DUAL BOOT with DOS.  You either boot up OS/2 or
> you boot up DOS+Windows -- any time you want.
> 
> 
> 
0
multicsfan (63)
1/3/2006 10:33:40 PM
<adaworks@sbcglobal.net> wrote in message
news:mIouf.45519$7h7.9229@newssvr21.news.prodigy.com...
>
> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> news:fQbuf.6955$2j2.893@fe11.lga...
> >
> > C also has the advantage of being married to the Unix architecture, and
> > almost every operating system around today (yes, even Windows, to the
> > extent that it can be) is based on that architecture.
> >
> This Quarter, I will be teaching an operating systems principles class.  We
will
> use Minix as the operating system that students modify and write programs to
> do experiments.  It is written in C.
>
> C, while being inexpensive, is also relatively simple and compact.  Sometimes
it
> is called a "universal assembler."   There have been other attempts to design
> such universal assemblers, but C endures.

S/360 assembler has been around for 40 years.  MIX about 35 years.

>    It is really easy to learn.  One does
> not have to know much to get started.   Pointers are a problem, but one
> eventually
> gets the hang of them.  It is an error-prone language, and everyone learns the
> importance of spending long hours debugging.
>
> Someone made a comment about not having access to PL/I because it is
> too expensive.   Ada originally had that problem since compiler publishers,
> believing they had a captive audience in the DoD charge exorbitant prices
> for compilers.  Now Ada compilers are availble for download, free.  Is
> PL/I available in a free download form?

PL/I compilers are available free for non-commercial use
from Kednos; also Digital Research PL/I (G subset)
The Kednos compiler runs on its native systems or under an
emulator (also free) on the PC.
Both compilers can be downloaded.

>   C is still one of the cheapest
> alternatives available for programming most platforms.

But tends to waste a lot of programmer time, and hence its
cost becomes considerably more than that of other compilers.

> Large languages such as PL/I, Ada, C++, Eiffel, and others can require a
> student to learn a lot before being productive.

I do not believe that that is the case with PL/I.  The G-level subset
provides a relatively well-endowed subset.  An even smaller subset
still has a lot of capability.  A series of subsets of increasing power
was taught under the general banner of SP/k.


0
robin_v (2737)
1/3/2006 10:44:38 PM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:v4ednVo2paxkYSTenZ2dnUVZ_tqdnZ2d@comcast.com...
> Peter Flass wrote:
> (snip)
>
> >> all the number oare considerd fixed decimal (1,0) compile time so all
> >> the math is done as fixed decimal (1,0) until the assignment is
> >> reached at which point the fixed decimal(1,0) number is converted to
> >> float bin.
>
> > I see where you're going with this, but binary or decimal, the results
> > should be the same.  This is a bad example, you need a division instead
> > of multiplication to potentially cause a problem, but what you want is
> > to evaluate this as FLOAT rather than FIXED, something like: a =
> > float(3)*4+2
>
> The indicated problem comes when fixed point hits the limit in the
> number of digits.

FIXEDOVERFLOW or SIZE catches that.

> > I don't have a manual handy that has the nice table, but for the F
> > compiler:
> >    multiplication:         p = p1 + p2 + 1
> >                            q = q1 + q2
> >    addition/subtraction:   p = 1 + max( p1-q1, p2-q2 ) + max( q1, q2 )
> >                            q = max( q1, q2 )
> > You're right, all your constants are FIXED DECIMAL(1,0)
> >   3*4 gives a FIXED DEC(3,0) result
> >   (3*4)+2 gives a FIXED DEC(4,0) result
> > So the FIXED DEC(4,0) value '14' will be correctly assigned to a.
>
> In addition, there is a limit on p...
>
> > Division can give strange results, but for FIXED division, PL/I attempts
> > to retain the largest possible number of fractional digits in the result
> > after allowing enough integer digits:
> >     p = M
> >     q = M - ( ( p1 - q1 ) + q2 )
> > where M is the maximum possible number of digits for the radix used.
>
> The old favorite example, 25+1/3 which is 5.33333333333333

No it's not.  This is trapped by FIXEDOVERFLOW.
The result of such an operation is underined.

>  (some number
> of 3's).   The same result should occur from 25+0.33333333333333 with
> no division, but it is much easier to do with division.

Again, FIXEDOVERFLOW traps this.
The result of such an operation is undefined.

> Both multiply and divide can easily generate more digits than either
> operand.

All arithmetic operations generate more digits than either operand
(including add and subtract), except when the operand(s)
already have the maximum number of digits.

>  With a maximum number of digits, there is no all around right
> answer.
>
> -- glen
>


0
robin_v (2737)
1/3/2006 11:09:37 PM
"multicsfan" <multicsfan@hotmail.com> wrote in message
news:8ZCuf.3733$i65.1807@trndny05...
> The problem was I needed windows all the time for
> windows stuff for work > realted stuff.  The PL/1
> was entierly personal.

Windows programs are accessed through the OS/2 desktop.


0
robin_v (2737)
1/3/2006 11:09:38 PM
robin wrote:
> "multicsfan" <multicsfan@hotmail.com> wrote in message
> news:8ZCuf.3733$i65.1807@trndny05...
>> The problem was I needed windows all the time for
>> windows stuff for work > realted stuff.  The PL/1
>> was entierly personal.
> 
> Windows programs are accessed through the OS/2 desktop.

Only now hopelessly obsolete Windows 3.1 (and earlier) programs.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/4/2006 12:57:16 AM
Tom Linden wrote:
> On Tue, 03 Jan 2006 06:20:02 GMT, <adaworks@sbcglobal.net> wrote:
> 
>> Large languages such as PL/I, Ada, C++, Eiffel, and others can require 
>> a student
>> to learn a lot before being productive.
> 
> You can actually write PL/I with very simple constructs, and you can make
> it successively more sophisticated, and no better language for 
> introducing the
> student to things like templates, linked lists and so on.

Yes, I think PL/I can claim that -- it is probably still the most 
powerful language that is both truly compilable and (mostly) easy for 
beginners. Ada, for example, requires rather too much "do this because I 
say so" for a mere "Hello, world!"

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/4/2006 1:02:36 AM
robin wrote:
> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> news:Hncuf.6969$2j2.1551@fe11.lga...
> 
>> The issue is not whether ON ENDFILE is /ever/ of any use, but whether it
>> was the right design for universal use.
> 
> It is clearly the right design for general use.
> It is required, at the very least, for stream input.
> Works wonders with record input too.
> 
>  (And the proposed case is
>> sloppy, anyway. Allocate a bigger-than-necessary array -- which also
>> requires the programmer to impose an arbitrary upper limit -- and then
>> either be stuck with that larger-than-necessary array -- pure 1950's
>> FORTRAN thinking -- or else create a second, smaller array and copy it.
>> Ugh!)
> 
> The relevance of this "bigger-than-necessary array" is?

If you know the size of your input, then you don't need ON ENDFILE. If 
you don't, then in order to use ON ENDFILE your way, you need to start 
your program with a worst-case buffer, which A) is wasteful and B) 
requires the programmer to supply a hard-coded worst case, which, in 
many instances, will crash someday.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/4/2006 1:06:00 AM
robin wrote:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:v4ednVo2paxkYSTenZ2dnUVZ_tqdnZ2d@comcast.com...

(snip)

>>>Division can give strange results, but for FIXED division, PL/I attempts
>>>to retain the largest possible number of fractional digits in the result
>>>after allowing enough integer digits:
>>>    p = M
>>>    q = M - ( ( p1 - q1 ) + q2 )
>>>where M is the maximum possible number of digits for the radix used.

>>The old favorite example, 25+1/3 which is 5.33333333333333

> No it's not.  This is trapped by FIXEDOVERFLOW.
> The result of such an operation is underined.

Unless one has NOFIXEDOVERFLOW active.

>> (some number
>>of 3's).   The same result should occur from 25+0.33333333333333 with
>>no division, but it is much easier to do with division.

> Again, FIXEDOVERFLOW traps this.
> The result of such an operation is undefined.

Again, only if there is no NOFIXEDOVERFLOW prefix.

>>Both multiply and divide can easily generate more digits
>> than either operand.

> All arithmetic operations generate more digits than either operand
> (including add and subtract), except when the operand(s)
> already have the maximum number of digits.

But multiply and divide do it much faster.

-- glen

0
gah (12851)
1/4/2006 8:51:55 AM
Everett M. Greene wrote:

> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

>>Part of the design of PL/I is that one should not need to learn the 
>>whole language.  That is one reason for no reserved words.
>>I would guess the amount of PL/I needed to start writing useful programs
>>is smaller than the amount of C, but it is hard to say.

>>printf, and especially scanf, are not easy to learn to use compared to 
>>PUT LIST and GET LIST, with PUT EDIT somewhere in between.

> I had a highly experienced C developer state that inexperienced
> programmers don't understand how to use scanf() while experienced
> programmers know to not use it.

It isn't quite that bad, but not so far, either.  It works somewhat 
better reading from a file than from direct keyboard input.

fgets with sscanf works a little better, though is significantly
more work, and is often what the more experienced programmers use.

-- glen

0
gah (12851)
1/4/2006 8:57:57 AM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:P8Fuf.1804$DY3.821@fe09.lga...
>
> Yes, I think PL/I can claim that -- it is probably still the most
> powerful language that is both truly compilable and (mostly) easy for
> beginners. Ada, for example, requires rather too much "do this because I
> say so" for a mere "Hello, world!"
>

Comparing langauges based on Hello World is not very useful.
It is much more interesting to see how a language scales up as programs
become more complicated in structure and algorithm.

But since you mention it,

           with Ada.Text_IO;  -- scope clause; no methods are directly visible
           procedure Hello_World is
           begin
               Ada.Text_IO.Put_Line("Hello World");  -- explicit visibility
through dot notation
           end Hello_World;
or
           with Ada.Text_IO;     -- scope clause
           use Ada.Text_IO;      -- visibility clause; make all methods directly
visible
           procedure Hello_World is
           begin
                Put_Line("Hello World");
           end Hello_World;

Input/Output is not a part of the language design.  There are different
I/O libraries for different data types and environments.

In contrast, a language that has IO built-in is BASIC,

           10 PRINT "Hello World"

In such languages, "Hello World" is not particularly complicated.

Most modern languages do not have IO built-in.  Rather, the contemporary
approach is to define a language and then rely on libraries for the IO. This
has significant advantages because of the growing variety of IO devices now
available.  In the case of object-oriented languages such as Eiffel, Smalltalk,
Java, and C++, the IO is implemented through class libraries.  This has
turned out to be the approach preferred by most computer science people.

When one uses separate libraries, there will almost always be some syntactic
code that imports or attaches the library to the program.   The increased
flexibility of this model has proven itself useful.   I think even PL/I has
taken
the external IO library approach to support for environments such as
Windows.



0
adaworks2 (748)
1/4/2006 9:43:25 AM
John W. Kennedy wrote:
> robin wrote:
> 
>> "multicsfan" <multicsfan@hotmail.com> wrote in message
>> news:8ZCuf.3733$i65.1807@trndny05...
>>
>>> The problem was I needed windows all the time for
>>> windows stuff for work > realted stuff.  The PL/1
>>> was entierly personal.
>>
>>
>> Windows programs are accessed through the OS/2 desktop.
> 
> 
> Only now hopelessly obsolete Windows 3.1 (and earlier) programs.
> 

Or with shareware Odin [or eCS], almost any winbloze program.

0
Peter_Flass (956)
1/4/2006 12:46:24 PM
adaworks@sbcglobal.net wrote:
> Most modern languages do not have IO built-in.  Rather, the contemporary
> approach is to define a language and then rely on libraries for the IO. This
> has significant advantages because of the growing variety of IO devices now
> available.  

To each his own, but I *strongly* disagree that this is desirable.  It's 
a holdover from C, which, with its minimalist approach would allow 
programs to be linked without any I/O at all.

One of the strengths of PL/I is that the I/O is part of the language and 
not an "add-in", so it's much more integrated with the compiled code 
than libraries usually are or can be.  The code is still implemented via 
libraries, it's the degree of interconnection that's important,

As far as supporting different devices, the ENVIRONMENT option and the 
OPTIONS keyword allow the language to be easily extended to support any 
device you want.  PL/I(F) used to support QTAM, not all that different 
from TCP, and PL/I has been used for realtime control of specialized 
devices.

0
Peter_Flass (956)
1/4/2006 12:54:38 PM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:P3Fuf.1786$DY3.334@fe09.lga...
> robin wrote:
> > "multicsfan" <multicsfan@hotmail.com> wrote in message
> > news:8ZCuf.3733$i65.1807@trndny05...
> >> The problem was I needed windows all the time for
> >> windows stuff for work > realted stuff.  The PL/1
> >> was entierly personal.
> >
> > Windows programs are accessed through the OS/2 desktop.
>
> Only now hopelessly obsolete Windows 3.1 (and earlier) programs.

Let me assure you that Word for 3.1 has fewer bugs than
later WORDs that can crash and lose all your work.


0
robin_v (2737)
1/4/2006 3:45:50 PM
<adaworks@sbcglobal.net> wrote in message
news:1NMuf.51594$6e1.29630@newssvr14.news.prodigy.com...
>
> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> news:P8Fuf.1804$DY3.821@fe09.lga...
> >
> > Yes, I think PL/I can claim that -- it is probably still the most
> > powerful language that is both truly compilable and (mostly) easy for
> > beginners. Ada, for example, requires rather too much "do this because I
> > say so" for a mere "Hello, world!"
>
> Comparing langauges based on Hello World is not very useful.
> It is much more interesting to see how a language scales up as programs
> become more complicated in structure and algorithm.
>
> But since you mention it,
>
>            with Ada.Text_IO;  -- scope clause; no methods are directly visible
>            procedure Hello_World is
>            begin
>                Ada.Text_IO.Put_Line("Hello World");  -- explicit visibility
> through dot notation
>            end Hello_World;
> or
>            with Ada.Text_IO;     -- scope clause
>            use Ada.Text_IO;      -- visibility clause; make all methods
directly
> visible
>            procedure Hello_World is
>            begin
>                 Put_Line("Hello World");
>            end Hello_World;
>
> Input/Output is not a part of the language design.  There are different
> I/O libraries for different data types and environments.
>
> In contrast, a language that has IO built-in is BASIC,
>
>            10 PRINT "Hello World"
>
> In such languages, "Hello World" is not particularly complicated.
>
> Most modern languages do not have IO built-in.  Rather, the contemporary
> approach is to define a language and then rely on libraries for the IO. This
> has significant advantages because of the growing variety of IO devices now
> available.

With the I/O defined in terms of procedure calls,
the compiler can't make a lot of sense as regards
diagnosing errors, and can give messages related
to procedure calls, rather than to the specific I/O
constructs.
    With input and output specified by specific input and
output statements, however, the compiler can give
explicit messages for syntax errors that actually relate
to an input or output statement.
    I/O for Algol 60 was typically implemented as procedure
calls, and as such was a real mess.  Likewise for C.

>  In the case of object-oriented languages such as Eiffel, Smalltalk,
> Java, and C++, the IO is implemented through class libraries.  This has
> turned out to be the approach preferred by most computer science people.
>
> When one uses separate libraries, there will almost always be some syntactic
> code that imports or attaches the library to the program.   The increased
> flexibility of this model has proven itself useful.   I think even PL/I has
> taken the external IO library approach to support for environments such as
> Windows.

Not really.  Some procedures were added for the XML processor,
which handles xtra long strings.



0
robin_v (2737)
1/4/2006 3:45:51 PM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:l7SdnZJjPIYvESbenZ2dnUVZ_v6dnZ2d@comcast.com...
> robin wrote:
> > "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> > news:v4ednVo2paxkYSTenZ2dnUVZ_tqdnZ2d@comcast.com...
>
> (snip)
>
> >>>Division can give strange results, but for FIXED division, PL/I attempts
> >>>to retain the largest possible number of fractional digits in the result
> >>>after allowing enough integer digits:
> >>>    p = M
> >>>    q = M - ( ( p1 - q1 ) + q2 )
> >>>where M is the maximum possible number of digits for the radix used.
>
> >>The old favorite example, 25+1/3 which is 5.33333333333333
>
> > No it's not.  This is trapped by FIXEDOVERFLOW.
> > The result of such an operation is underined.
>
> Unless one has NOFIXEDOVERFLOW active.

FIXEDOVERFLOW is ACTIVE by default.
In any case, a program that experiences an overflow is in
error, and results are not defined.

> >> (some number
> >>of 3's).   The same result should occur from 25+0.33333333333333 with
> >>no division, but it is much easier to do with division.
>
> > Again, FIXEDOVERFLOW traps this.
> > The result of such an operation is undefined.
>
> Again, only if there is no NOFIXEDOVERFLOW prefix.

A program that experiences overflow is in error, and the
result is undefined.
That's why FIXEDOVERFLOW is enabled by default.
Not only does FIXEDOVERF\LOW need to be enabled,
SIZE also.

> >>Both multiply and divide can easily generate more digits
> >> than either operand.
>
> > All arithmetic operations generate more digits than either operand
> > (including add and subtract), except when the operand(s)
> > already have the maximum number of digits.
>
> But multiply and divide do it much faster.

Multiply and divide are slow operations.  Add and subtract will
overflow quicker.


0
robin_v (2737)
1/4/2006 3:45:52 PM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:_bFuf.1816$DY3.562@fe09.lga...
> robin wrote:
> > "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> > news:Hncuf.6969$2j2.1551@fe11.lga...
> >
> >> The issue is not whether ON ENDFILE is /ever/ of any use, but whether it
> >> was the right design for universal use.
> >
> > It is clearly the right design for general use.
> > It is required, at the very least, for stream input.
> > Works wonders with record input too.
> >
> >  (And the proposed case is
> >> sloppy, anyway. Allocate a bigger-than-necessary array -- which also
> >> requires the programmer to impose an arbitrary upper limit -- and then
> >> either be stuck with that larger-than-necessary array -- pure 1950's
> >> FORTRAN thinking -- or else create a second, smaller array and copy it.
> >> Ugh!)
> >
> > The relevance of this "bigger-than-necessary array" is?
>
> If you know the size of your input, then you don't need ON ENDFILE.

Q: What is the ENDFILE condition for?  A: For detecting end-of-file.

    Even knowing the number of elements to be input,
there's no guarantee that there will be exactly that number of elements.
It is, in general,, necessary to ensure that the input stream is not short.
It may even be necessary to verify that there are no superfluous
values (i.e., extra ones that will otherwise become missed ones).

     It is necessary fot the programmer to cater for all contingencies.

    The ENDFILE condition needs to be available and ready to detect
such ocurrrences.

> If
> you don't, then in order to use ON ENDFILE your way, you need to start
> your program with a worst-case buffer, which A) is wasteful

On the contrary, that is entirely unnecessary, and an unknown
quantity of data can be read in and stored in an array of precisely
size required.  There are no hard limits (other than the maximum
array size permitted by the software).

> and B)
> requires the programmer to supply a hard-coded worst case, which, in
> many instances, will crash someday.

Again, that is nonsense; please read the above (A).


0
robin_v (2737)
1/4/2006 3:45:55 PM
robin wrote:
> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> news:P3Fuf.1786$DY3.334@fe09.lga...
> 
>>robin wrote:
>>
>>>"multicsfan" <multicsfan@hotmail.com> wrote in message
>>>news:8ZCuf.3733$i65.1807@trndny05...
>>>
>>>>The problem was I needed windows all the time for
>>>>windows stuff for work > realted stuff.  The PL/1
>>>>was entierly personal.
>>>
>>>Windows programs are accessed through the OS/2 desktop.
>>
>>Only now hopelessly obsolete Windows 3.1 (and earlier) programs.
> 
> 
> Let me assure you that Word for 3.1 has fewer bugs than
> later WORDs that can crash and lose all your work.
> 
> 
While I run one of everything I still use Windows 3.1 (DOS 6.22) as my 
isolated machine (not connected to anything) for confidential work.  The 
machine has neither crashed nor lost any data in the last ten years.

Also, at 166 MHz it boots faster than my 1 GHz Win98SE which boots 
faster than my 2 GHz Win2K which boots faster than my WinXPpro.  Go figure.
0
donaldldobbs (108)
1/4/2006 5:25:50 PM
adaworks@sbcglobal.net wrote:
> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> news:P8Fuf.1804$DY3.821@fe09.lga...
>> Yes, I think PL/I can claim that -- it is probably still the most
>> powerful language that is both truly compilable and (mostly) easy for
>> beginners. Ada, for example, requires rather too much "do this because I
>> say so" for a mere "Hello, world!"
>>
> 
> Comparing langauges based on Hello World is not very useful.
> It is much more interesting to see how a language scales up as programs
> become more complicated in structure and algorithm.

I agree -- but that's not the same thing as "easy for beginners".

> In contrast, a language that has IO built-in is BASIC,

>            10 PRINT "Hello World"

> In such languages, "Hello World" is not particularly complicated.

Yes, but everything else, from data declaration on, is.

> Most modern languages do not have IO built-in.  Rather, the contemporary
> approach is to define a language and then rely on libraries for the IO. This
> has significant advantages because of the growing variety of IO devices now
> available.  In the case of object-oriented languages such as Eiffel, Smalltalk,
> Java, and C++, the IO is implemented through class libraries.  This has
> turned out to be the approach preferred by most computer science people.

Provided that the library be /done/. (ALGOL 60 tripped up badly on that.)

> When one uses separate libraries, there will almost always be some syntactic
> code that imports or attaches the library to the program.   The increased
> flexibility of this model has proven itself useful.   I think even PL/I has
> taken
> the external IO library approach to support for environments such as
> Windows.

Inevitably, as the semantics are not portable without the huge effort 
that has gone into Java Swing.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/4/2006 5:38:30 PM
Peter Flass wrote:
> adaworks@sbcglobal.net wrote:
>> Most modern languages do not have IO built-in.  Rather, the contemporary
>> approach is to define a language and then rely on libraries for the 
>> IO. This
>> has significant advantages because of the growing variety of IO 
>> devices now
>> available.  
> 
> To each his own, but I *strongly* disagree that this is desirable.  It's 
> a holdover from C, which, with its minimalist approach would allow 
> programs to be linked without any I/O at all.

It didn't start with C.

> One of the strengths of PL/I is that the I/O is part of the language and 
> not an "add-in", so it's much more integrated with the compiled code 
> than libraries usually are or can be.  The code is still implemented via 
> libraries, it's the degree of interconnection that's important,

But it isn't of much use to modern programming, which generally requires 
external calls (of some sort) to handle GUIs, databases, XML, and other 
real-world interfaces.

> As far as supporting different devices, the ENVIRONMENT option and the 
> OPTIONS keyword allow the language to be easily extended to support any 
> device you want.  PL/I(F) used to support QTAM, not all that different 
> from TCP, and PL/I has been used for realtime control of specialized 
> devices.

And the Optimizing Compiler supported TCAM, which replaced QTAM. But I 
found it far more practical to write my own BTAM interface in Assembler 
and call that.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/4/2006 5:46:37 PM
robin wrote:
  > With the I/O defined in terms of procedure calls,
> the compiler can't make a lot of sense as regards
> diagnosing errors, and can give messages related
> to procedure calls, rather than to the specific I/O
> constructs.

I suppose that applies to the C printf and scanf family of functions, 
but it is not generally true.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/4/2006 5:52:06 PM
robin wrote:
> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> news:_bFuf.1816$DY3.562@fe09.lga...
>> robin wrote:
>>> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
>>> news:Hncuf.6969$2j2.1551@fe11.lga...
>>>
>>>> The issue is not whether ON ENDFILE is /ever/ of any use, but whether it
>>>> was the right design for universal use.
>>> It is clearly the right design for general use.
>>> It is required, at the very least, for stream input.
>>> Works wonders with record input too.
>>>
>>>  (And the proposed case is
>>>> sloppy, anyway. Allocate a bigger-than-necessary array -- which also
>>>> requires the programmer to impose an arbitrary upper limit -- and then
>>>> either be stuck with that larger-than-necessary array -- pure 1950's
>>>> FORTRAN thinking -- or else create a second, smaller array and copy it.
>>>> Ugh!)
>>> The relevance of this "bigger-than-necessary array" is?
>> If you know the size of your input, then you don't need ON ENDFILE.
> 
> Q: What is the ENDFILE condition for?  A: For detecting end-of-file.

Your steadfast refusal to admit that there is a distinction between 
catching an error in input structure and handling the normal end-of-file 
condition makes further prolongation of this thread pointless.

PL/I was not handed down to Moses on Mt. Sinai.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/4/2006 5:55:46 PM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:iAPuf.50632$XJ5.16483@twister.nyroc.rr.com...
>
> To each his own, but I *strongly* disagree that this is desirable.  It's
> a holdover from C, which, with its minimalist approach would allow
> programs to be linked without any I/O at all.
>
I began my computing career using languages that had all th I/O built-in.
It took a little while to get used to the idea of using languages in which
I/O is implemented using separate libraries.

Incidentally, this did not originate with C, but it certainly has been
popularized
by C.   I am no fan of C.   I dislike it, for the most part.  I also don't like
C++ for anything important or where reliability is a desired outcome.
>
> One of the strengths of PL/I is that the I/O is part of the language and
> not an "add-in", so it's much more integrated with the compiled code
> than libraries usually are or can be.  The code is still implemented via
> libraries, it's the degree of interconnection that's important,
>
In software development tools, every benefit seems to have a corresponding
liability.   You suggest that "add-in" is a bad thing.  Some would disagree that
this simply means the language is flexible enough to support extension.   Since
the I/O code is written in the underlying language, the interconnection is
usually
quite good.  For most modern languages this is not a problem.

It also reduces the number of reserved words in the language.  OK, one might
way that the presence of reserved words (and keywords) increases the ability
of the compiler to detect errors.   That is true for compilers designed in that
way.  It is not the only truth, though.  I have worked with languages that
are highly reliable where the I/O libraries are written separately.

I have not noticed any degradation of reliability due to the decoupling of
I/O from the core language specification.   Further, it this were as horrid
as some suggest, it would have lost credibility a long time ago.  Then again,
people still insist on using C and C++, so that fact that something is horrid
seems to have little effect on some people.
>
> As far as supporting different devices, the ENVIRONMENT option and the
> OPTIONS keyword allow the language to be easily extended to support any
> device you want.  PL/I(F) used to support QTAM, not all that different
> from TCP, and PL/I has been used for realtime control of specialized
> devices.
>
It is not that the PL/I approach is wrong.   There are many ways to design
languages and systems.   At the same time, the alternative approach is not
wrong either.  It is simply a difference in design philosophy.  There are
benefits
for each approach.

However, the current trend in language design is to decouple the I/O concerns
from the rest of the language.  One could look at this as a variation of the
Model-View-Controller approach.  Or, it could be viewed as a kind of
loose-coupling/high-cohesion design, a design model that has taken on
significant importance in modern software development.

Further, programming language design, in the future, is likely to move more
and more toward loose-coupling, not just of I/O, but of other language
features.   It is simply an alternative approach to design, and it works well
for those who choose to use it.

Richard Riehle



0
adaworks2 (748)
1/6/2006 1:55:09 AM
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:j2Utf.6823$2j2.2284@fe11.lga...

> Anonymous pointers were a mistake.

This is probably true since most languages have made mistakes
with pointers, including PL/I, C, and others.    The problem seems
to be the fact that it is so easy to create dangling references as
well as unreachable storage.

While this is a weakness of languages that include pointers, it is
a known weakness and disciplined programmers take it seriously
in the design of their programs.

Java has taken the decision to avoid direct manipulation of pointers
by the programmer.  Indirection is implicit rather than explicit.  This
eliminates the problem on one hand, but introduces a whole new
set of problems.

Richard Riehle


0
adaworks2 (748)
1/6/2006 2:09:04 AM
On Fri, 06 Jan 2006 02:09:04 GMT, <adaworks@sbcglobal.net> wrote:

>
> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> news:j2Utf.6823$2j2.2284@fe11.lga...
>
>> Anonymous pointers were a mistake.
>
> This is probably true since most languages have made mistakes
> with pointers, including PL/I, C, and others.    The problem seems
> to be the fact that it is so easy to create dangling references as
> well as unreachable storage.

I have never regarded this as a mistake in PL/I, I consider it an
advantage.  If you are trying to provide tools for mediocre prgrammers
restrict them to AREAs and OFFSETs
>
> While this is a weakness of languages that include pointers, it is
> a known weakness and disciplined programmers take it seriously
> in the design of their programs.
>
> Java has taken the decision to avoid direct manipulation of pointers
> by the programmer.  Indirection is implicit rather than explicit.  This
> eliminates the problem on one hand, but introduces a whole new
> set of problems.
>
> Richard Riehle
>
>

0
tom284 (1839)
1/6/2006 1:25:36 PM
On Fri, 06 Jan 2006 01:55:09 GMT, <adaworks@sbcglobal.net> wrote:

> I have not noticed any degradation of reliability due to the decoupling  
> of
> I/O from the core language specification.   Further, it this were as  
> horrid
> as some suggest, it would have lost credibility a long time ago.  Then  
> again,
> people still insist on using C and C++, so that fact that something is  
> horrid
> seems to have little effect on some people.

Richard, what you are overlooking is the ability of the compiler to  
diagnose
usage at compile time, and therby better enforce the interface  
specifications
to the runtime library, which otherwise must do it all at run time.
0
tom284 (1839)
1/6/2006 1:34:29 PM
"Tom Linden" <tom@kednos.com> wrote in message
news:ops2ykwymfzgicya@hyrrokkin...
> On Fri, 06 Jan 2006 02:09:04 GMT, <adaworks@sbcglobal.net> wrote:
>
> >
> > "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> > news:j2Utf.6823$2j2.2284@fe11.lga...
> >
> >> Anonymous pointers were a mistake.
> >
> > This is probably true since most languages have made mistakes
> > with pointers, including PL/I, C, and others.    The problem seems
> > to be the fact that it is so easy to create dangling references as
> > well as unreachable storage.
>
> I have never regarded this as a mistake in PL/I, I consider it an
> advantage.  If you are trying to provide tools for mediocre prgrammers
> restrict them to AREAs and OFFSETs
> >
Most people who specialize in programming language design see the
pointer design of PL/I as a bad thing.  From Sebesta's book on
comparative programming languages:

       "Pointers were included as a data type, although they were not as
         safe to use as those in later languages."

      P/I " ... pointers are highly flexible but can lead to several kinds of
           programming error ... "

Also, this code fragment,

         BEGIN;
         DECLARE POINT POINTER;
            ...
              BEGIN;
              DECLARE SUM FIXED;
              POINT = ADDR(SUM);
               ...
              END;
       END;

Notice that POINT still references a value, SUM, from
the inner block, after leaving that block.   This creates
a dangling reference.

Consider the following code.

       DECLARE SUM FLOAT BASED (POINT);
       DECLARE POINT2 POINTER;
           ...
       ALLOCATE SUM;
       POINT2 = SUM;
       FREE SUM;

In this example, POINT2 is now a dangling pointer.  The compiler
did not used to provide a warning.  Perhaps this has changed, but it
was, at one time, a problem.

Consider the following problem with ALLOCATE.

       DECLARE SUM FLOAT BASED (POINT);
            ...
       ALLOCATE SUM;

              ...
       ALLOCATE SUM;

After the first dynamic allocation, the first object still exists.  Again,
a modern PL/I compiler might provide a warning, but this was not
true of earlier compilers.   We have a dangling object, not a dangling
reference.   At least this simply consumes storage rather than creating
a possible program error.

To be fair, the problems just shown are not unique to PL/I.   The challenges
of indirection are difficult and lots of language designers have jumped through
hoops to solve them.  The success of these solutions has varied a lot.
Languages
such Python solve this by making everything an implied reference.   Java takes
a halfway solution in this regard (scalars are not by reference).   C is just
plain
dangerous.  C++ has tightened up the restrictions we used to have with void
pointers.

I don't think we can easily dismiss the concern by blaming mediocre programmers.
I have seen experience programmers make mistakes they might not have made if
they were completely on-their-game.   I have certainly made stupid mistakes over
the years, and still do from time to time.  Pointers are a source of errors.
Compilers
need to at least warn the programmer about potential problems, or prevent them
from
creating unsafe constructs, whenever they can detect those problems.

Richard Riehle



0
adaworks2 (748)
1/6/2006 6:01:46 PM

adaworks@sbcglobal.net wrote:
> "Tom Linden" <tom@kednos.com> wrote in message
> news:ops2ykwymfzgicya@hyrrokkin...
> 
>>On Fri, 06 Jan 2006 02:09:04 GMT, <adaworks@sbcglobal.net> wrote:
>>
>>
>>>"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
>>>news:j2Utf.6823$2j2.2284@fe11.lga...
>>>
>>>
>>>>Anonymous pointers were a mistake.
>>>
>>>This is probably true since most languages have made mistakes
>>>with pointers, including PL/I, C, and others.    The problem seems
>>>to be the fact that it is so easy to create dangling references as
>>>well as unreachable storage.
>>
>>I have never regarded this as a mistake in PL/I, I consider it an
>>advantage.  If you are trying to provide tools for mediocre prgrammers
>>restrict them to AREAs and OFFSETs
>>
> Most people who specialize in programming language design see the
> pointer design of PL/I as a bad thing.  From Sebesta's book on
> comparative programming languages:
> 
>        "Pointers were included as a data type, although they were not as
>          safe to use as those in later languages."
> 
>       P/I " ... pointers are highly flexible but can lead to several kinds of
>            programming error ... "
> 
> Also, this code fragment,
> 
>          BEGIN;
>          DECLARE POINT POINTER;
>             ...
>               BEGIN;
>               DECLARE SUM FIXED;
>               POINT = ADDR(SUM);
>                ...
>               END;
>        END;
> 
> Notice that POINT still references a value, SUM, from
> the inner block, after leaving that block.   This creates
> a dangling reference.
> 
> Consider the following code.
> 
>        DECLARE SUM FLOAT BASED (POINT);
>        DECLARE POINT2 POINTER;
>            ...
>        ALLOCATE SUM;
>        POINT2 = SUM;
>        FREE SUM;
> 
> In this example, POINT2 is now a dangling pointer.  The compiler
> did not used to provide a warning.  Perhaps this has changed, but it
> was, at one time, a problem.
> 
> Consider the following problem with ALLOCATE.
> 
>        DECLARE SUM FLOAT BASED (POINT);
>             ...
>        ALLOCATE SUM;
> 
>               ...
>        ALLOCATE SUM;
> 
> After the first dynamic allocation, the first object still exists.  Again,
> a modern PL/I compiler might provide a warning, but this was not
> true of earlier compilers.   We have a dangling object, not a dangling
> reference.   At least this simply consumes storage rather than creating
> a possible program error.
> 
> To be fair, the problems just shown are not unique to PL/I.   The challenges
> of indirection are difficult and lots of language designers have jumped through
> hoops to solve them.  The success of these solutions has varied a lot.
> Languages
> such Python solve this by making everything an implied reference.   Java takes
> a halfway solution in this regard (scalars are not by reference).   C is just
> plain
> dangerous.  C++ has tightened up the restrictions we used to have with void
> pointers.
> 
> I don't think we can easily dismiss the concern by blaming mediocre programmers.
> I have seen experience programmers make mistakes they might not have made if
> they were completely on-their-game.   I have certainly made stupid mistakes over
> the years, and still do from time to time.  Pointers are a source of errors.
> Compilers
> need to at least warn the programmer about potential problems, or prevent them
> from
> creating unsafe constructs, whenever they can detect those problems.
> 
> Richard Riehle
> 
While there may be some truth in what you say, maybe we should just 
eliminate pointers altogether from all HLLs since they are so danerous 
for unsuspecting programmers.

Oh, and while we're about it, let's eliminate guns, knives, cars, and 
airplanes because they are dangerous and even kill people.
0
donaldldobbs (108)
1/6/2006 6:18:25 PM
On Fri, 06 Jan 2006 18:01:46 GMT, <adaworks@sbcglobal.net> wrote:

>
> "Tom Linden" <tom@kednos.com> wrote in message
> news:ops2ykwymfzgicya@hyrrokkin...
>> On Fri, 06 Jan 2006 02:09:04 GMT, <adaworks@sbcglobal.net> wrote:
>>
>> >
>> > "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
>> > news:j2Utf.6823$2j2.2284@fe11.lga...
>> >
>> >> Anonymous pointers were a mistake.
>> >
>> > This is probably true since most languages have made mistakes
>> > with pointers, including PL/I, C, and others.    The problem seems
>> > to be the fact that it is so easy to create dangling references as
>> > well as unreachable storage.
>>
>> I have never regarded this as a mistake in PL/I, I consider it an
>> advantage.  If you are trying to provide tools for mediocre prgrammers
>> restrict them to AREAs and OFFSETs
>> >
> Most people who specialize in programming language design see the
> pointer design of PL/I as a bad thing.  From Sebesta's book on
> comparative programming languages:
>
>        "Pointers were included as a data type, although they were not as
>          safe to use as those in later languages."
>
>       P/I " ... pointers are highly flexible but can lead to several  
> kinds of
>            programming error ... "
>
> Also, this code fragment,
>
>          BEGIN;
>          DECLARE POINT POINTER;
>             ...
>               BEGIN;
>               DECLARE SUM FIXED;
>               POINT = ADDR(SUM);
>                ...
>               END;
>        END;
>

While the fragment does illustrate a potential problem, it is incorrect  
code.
I can't ever see writing code like that.  You can construct pathological
examples in any language I am sure, the concept of scope is a valid  
consideration
when designing PL/I code.  It would not be difficult to extend the  
compiler to
issue an access violation in the above case, since sum is allocated on the  
stack
and any use of point thereafter would be beyond the current stack  
pointer.  But,
as I said this, while licit is incorrect code, and I don't think it is  
necessary
to cater for such locutions

> Notice that POINT still references a value, SUM, from
> the inner block, after leaving that block.   This creates
> a dangling reference.
>
> Consider the following code.
>
>        DECLARE SUM FLOAT BASED (POINT);
>        DECLARE POINT2 POINTER;
>            ...
>        ALLOCATE SUM;
>        POINT2 = SUM;
>        FREE SUM;
>

In one of our PL/I implementation we actually assigned NULL() to the
pointer for such constructs,  how closely should we hold the programmers  
hand?

> In this example, POINT2 is now a dangling pointer.  The compiler
> did not used to provide a warning.  Perhaps this has changed, but it
> was, at one time, a problem.
>
> Consider the following problem with ALLOCATE.
>
>        DECLARE SUM FLOAT BASED (POINT);
>             ...
>        ALLOCATE SUM;
>
>               ...
>        ALLOCATE SUM;

Again, while licit code, it is in error.   Do you really want the compiler
to correct the programmer's errors?  Either the programmer forgot to FREE
or he wanted CONTROLLED allocation, or he wanted a list of pointers, or ...
>
> After the first dynamic allocation, the first object still exists.   
> Again,
> a modern PL/I compiler might provide a warning, but this was not
> true of earlier compilers.   We have a dangling object, not a dangling
> reference.   At least this simply consumes storage rather than creating
> a possible program error.
>
> To be fair, the problems just shown are not unique to PL/I.   The  
> challenges
> of indirection are difficult and lots of language designers have jumped  
> through
> hoops to solve them.  The success of these solutions has varied a lot.
> Languages
> such Python solve this by making everything an implied reference.   Java  
> takes
> a halfway solution in this regard (scalars are not by reference).   C is  
> just
> plain
> dangerous.  C++ has tightened up the restrictions we used to have with  
> void
> pointers.
>
> I don't think we can easily dismiss the concern by blaming mediocre  
> programmers.
> I have seen experience programmers make mistakes they might not have  
> made if
> they were completely on-their-game.   I have certainly made stupid  
> mistakes over
> the years, and still do from time to time.  Pointers are a source of  
> errors.
> Compilers
> need to at least warn the programmer about potential problems, or  
> prevent them
> from
> creating unsafe constructs, whenever they can detect those problems.
>
> Richard Riehle
>
>
>

0
tom284 (1839)
1/6/2006 6:43:02 PM
Happy New Year, Don.
Tom
> On Fri, 06 Jan 2006 10:18:25 -0800, Donald L. Dobbs  
> <donaldldobbs@cox.net> wrote:
>
> adaworks@sbcglobal.net wrote:
>> "Tom Linden" <tom@kednos.com> wrote in message
>> news:ops2ykwymfzgicya@hyrrokkin...
>>
>>> On Fri, 06 Jan 2006 02:09:04 GMT, <adaworks@sbcglobal.net> wrote:
>>>
>>>
>>>> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
>>>> news:j2Utf.6823$2j2.2284@fe11.lga...
>>>>
>>>>
>>>>> Anonymous pointers were a mistake.
>>>>
>>>> This is probably true since most languages have made mistakes
>>>> with pointers, including PL/I, C, and others.    The problem seems
>>>> to be the fact that it is so easy to create dangling references as
>>>> well as unreachable storage.
>>>
>>> I have never regarded this as a mistake in PL/I, I consider it an
>>> advantage.  If you are trying to provide tools for mediocre prgrammers
>>> restrict them to AREAs and OFFSETs
>>>
>> Most people who specialize in programming language design see the
>> pointer design of PL/I as a bad thing.  From Sebesta's book on
>> comparative programming languages:
>>         "Pointers were included as a data type, although they were not  
>> as
>>          safe to use as those in later languages."
>>        P/I " ... pointers are highly flexible but can lead to several  
>> kinds of
>>            programming error ... "
>>  Also, this code fragment,
>>           BEGIN;
>>          DECLARE POINT POINTER;
>>             ...
>>               BEGIN;
>>               DECLARE SUM FIXED;
>>               POINT = ADDR(SUM);
>>                ...
>>               END;
>>        END;
>>  Notice that POINT still references a value, SUM, from
>> the inner block, after leaving that block.   This creates
>> a dangling reference.
>>  Consider the following code.
>>         DECLARE SUM FLOAT BASED (POINT);
>>        DECLARE POINT2 POINTER;
>>            ...
>>        ALLOCATE SUM;
>>        POINT2 = SUM;
>>        FREE SUM;
>>  In this example, POINT2 is now a dangling pointer.  The compiler
>> did not used to provide a warning.  Perhaps this has changed, but it
>> was, at one time, a problem.
>>  Consider the following problem with ALLOCATE.
>>         DECLARE SUM FLOAT BASED (POINT);
>>             ...
>>        ALLOCATE SUM;
>>                ...
>>        ALLOCATE SUM;
>>  After the first dynamic allocation, the first object still exists.   
>> Again,
>> a modern PL/I compiler might provide a warning, but this was not
>> true of earlier compilers.   We have a dangling object, not a dangling
>> reference.   At least this simply consumes storage rather than creating
>> a possible program error.
>>  To be fair, the problems just shown are not unique to PL/I.   The  
>> challenges
>> of indirection are difficult and lots of language designers have jumped  
>> through
>> hoops to solve them.  The success of these solutions has varied a lot.
>> Languages
>> such Python solve this by making everything an implied reference.    
>> Java takes
>> a halfway solution in this regard (scalars are not by reference).   C  
>> is just
>> plain
>> dangerous.  C++ has tightened up the restrictions we used to have with  
>> void
>> pointers.
>>  I don't think we can easily dismiss the concern by blaming mediocre  
>> programmers.
>> I have seen experience programmers make mistakes they might not have  
>> made if
>> they were completely on-their-game.   I have certainly made stupid  
>> mistakes over
>> the years, and still do from time to time.  Pointers are a source of  
>> errors.
>> Compilers
>> need to at least warn the programmer about potential problems, or  
>> prevent them
>> from
>> creating unsafe constructs, whenever they can detect those problems.
>>  Richard Riehle
>>
> While there may be some truth in what you say, maybe we should just  
> eliminate pointers altogether from all HLLs since they are so danerous  
> for unsuspecting programmers.
>
> Oh, and while we're about it, let's eliminate guns, knives, cars, and  
> airplanes because they are dangerous and even kill people.

0
tom284 (1839)
1/6/2006 6:46:26 PM
"Tom Linden" <tom@kednos.com> wrote in message
news:ops2ylbrapzgicya@hyrrokkin...
> On Fri, 06 Jan 2006 01:55:09 GMT, <adaworks@sbcglobal.net> wrote:
>
> > I have not noticed any degradation of reliability due to the decoupling
> > of
> > I/O from the core language specification.   Further, it this were as
> > horrid
> > as some suggest, it would have lost credibility a long time ago.  Then
> > again,
> > people still insist on using C and C++, so that fact that something is
> > horrid
> > seems to have little effect on some people.
>
> Richard, what you are overlooking is the ability of the compiler to
> diagnose
> usage at compile time, and therby better enforce the interface
> specifications
> to the runtime library, which otherwise must do it all at run time.

The decoupling approach has not resulted in any degradation
of reliability in Ada.  I think both approaches are equally OK,
but the construction of the compiler will certainly be a little
different.

Richard


0
adaworks2 (748)
1/6/2006 8:36:04 PM
Donald L. Dobbs wrote:

> While there may be some truth in what you say, maybe we should just 
> eliminate pointers altogether from all HLLs since they are so danerous 
> for unsuspecting programmers.
> 
You may have something there.  How about writing a letter to CACM?  You 
could title it "Pointers Considered Harmful".  :-)


Bob Lidral
lidral  at  alum  dot  mit  dot  edu
0
1/6/2006 8:42:08 PM
"Tom Linden" <tom@kednos.com> wrote in message
news:ops2yzl0mvzgicya@hyrrokkin...
> On Fri, 06 Jan 2006 18:01:46 GMT, <adaworks@sbcglobal.net> wrote:
> .
> I can't ever see writing code like that.  You can construct pathological
> examples in any language I am sure, the concept of scope is a valid
> consideration when designing PL/I code.  It would not be difficult to extend
the
> compiler to issue an access violation in the above case, since sum is
allocated on the
> stack and any use of point thereafter would be beyond the current stack
> pointer.  But, as I said this, while licit is incorrect code, and I don't
think it is
> necessary to cater for such locutions
>
OK.  I admit that the examples I posted where unlikely to be coded by
knowledgeable and careful programmers.  Also, the potential for dangling
pointers is not unique to PL/I.   C and C++ also have this problem.  It is
a possible concern in any language that supports pointers, though some
languages have taken steps, such as those you mention in your reply,
to prevent such things.

Don Dobbs remark about guns, knives, etc. is noteworthy.   Some languages
such as Java have eliminated the issue of pointers from the immediate concern
of the programmers.  This also introduces a whole new set of concerns.  Python
makes every declaration dependent on indirection.   This is a good idea, but
creates an overhead not tolerable for some circumstances.

So, it is not a good idea to entirely eliminate the capability for indirection.
However,
because this is often the most difficult source of errors to debug, and because
it
is so easy to create such errors, the combination of language design and
compiler
design ought to go a little further to reduce the frequency of them.

Tom suggests that one could "extend the compiler to issue an access violation in
the above case."  Some compilers for some languages do just that.   PL/I
compilers
are not as dismally bad as C compilers (and some C++ compilers) in failing to
warn (yes warn, not mollycoddle) the programmer of a possible access violation.
I think Tom's idea is actually a very good one.

Richard Riehle


0
adaworks2 (748)
1/6/2006 8:52:28 PM
Tom Linden wrote:

> On Fri, 06 Jan 2006 18:01:46 GMT, <adaworks@sbcglobal.net> wrote:
> 
>>
>> [...]
>>
>> Consider the following problem with ALLOCATE.
>>
>>        DECLARE SUM FLOAT BASED (POINT);
>>             ...
>>        ALLOCATE SUM;
>>
>>               ...
>>        ALLOCATE SUM;
> 
> 
> Again, while licit code, it is in error.   Do you really want the compiler
> to correct the programmer's errors?  Either the programmer forgot to FREE
> or he wanted CONTROLLED allocation, or he wanted a list of pointers, or ...
> 
Actually, in the absence of more information about the code represented
by the ellipsis, we can't determine whether the example is in error.
Perhaps the intervening code contains references to SUM or POINT or
invokes procedures that do.  Such code could be used to allocate
successive entries in a list if the value of POINT were saved somewhere
somewhere in the intervening code.  [Although I'm having a hard time
thinking of anything useful to do with a list of FLOAT values with no
further information associated with each.]

>>
>> After the first dynamic allocation, the first object still exists.   
>> Again,
>> a modern PL/I compiler might provide a warning, but this was not
>> true of earlier compilers.   We have a dangling object, not a dangling
>> reference.   At least this simply consumes storage rather than creating
>> a possible program error.
>>
>> [...]
>>
>> I don't think we can easily dismiss the concern by blaming mediocre  
>> programmers.
>> I have seen experience programmers make mistakes they might not have  
>> made if
>> they were completely on-their-game.   I have certainly made stupid  
>> mistakes over
>> the years, and still do from time to time.  Pointers are a source of  
>> errors.
>> Compilers
>> need to at least warn the programmer about potential problems, or  
>> prevent them
>> from
>> creating unsafe constructs, whenever they can detect those problems.
>>
I have a few favorite management, sales, and marketing misconceptions
and you've just touched on one of them: that somehow cramming more work
hours into a (short) time span increases the amount of work
accomplished.  For example: working overtime increases productivity.
Once a certain point is passed, exhaustion, foul temper, resentment,
outside pressures (e.g.,  family), etc. cause loss of concentrarion,
leading to "stupid" mistakes which can more than offset any possible
increase in work output.  Given the management and sales pressures on
programmers, even good programmers should be expected to make some
"stupid" mistakes now and then.

I was going to list a few others of my favorite misconceptions, but
you're already probably familiar with all of them; it not, see Dilbert.  :-)

>> Richard Riehle


Bob Lidral
lidral  at  alum  dot  mit  dot  edu


0
1/6/2006 9:16:22 PM
Bob Lidral wrote:
> Donald L. Dobbs wrote:
> 
>> While there may be some truth in what you say, maybe we should just 
>> eliminate pointers altogether from all HLLs since they are so danerous 
>> for unsuspecting programmers.
>>
> You may have something there.  How about writing a letter to CACM?  You 
> could title it "Pointers Considered Harmful".  :-)
> 
> 
> Bob Lidral
> lidral  at  alum  dot  mit  dot  edu
I once worked with a fellow who removed all references to tables in 
programs that he worked on because he thought programmers made too many 
errors using tables.

Richard Brady
0
rrllbrrady (106)
1/6/2006 10:29:55 PM

adaworks@sbcglobal.net wrote:
> "Tom Linden" <tom@kednos.com> wrote in message
> news:ops2yzl0mvzgicya@hyrrokkin...
> 
>>On Fri, 06 Jan 2006 18:01:46 GMT, <adaworks@sbcglobal.net> wrote:
>>.
>>I can't ever see writing code like that.  You can construct pathological
>>examples in any language I am sure, the concept of scope is a valid
>>consideration when designing PL/I code.  It would not be difficult to extend
> 
> the
> 
>>compiler to issue an access violation in the above case, since sum is
> 
> allocated on the
> 
>>stack and any use of point thereafter would be beyond the current stack
>>pointer.  But, as I said this, while licit is incorrect code, and I don't
> 
> think it is
> 
>>necessary to cater for such locutions
>>
> 
> OK.  I admit that the examples I posted where unlikely to be coded by
> knowledgeable and careful programmers.  

In the 40 years that I have been using PL/I (I was part of a PL/I beta 
site in 1965) from mainframes to micros I have never had a memory leak 
or a dangling anything.  I don't consider myself an exceptional 
programmer skillwise -- just one who follows the rules and is very 
careful and deliberate when playing with fire (using pointers) in the 
same way I don't point a loaded gun at anyone.

As an aside: one of the reasons I really enjoy assembler language (on 
any platform) is that I can avoid the religious wars and I am in an 
environment where the pointy-headed academics who never earned a living 
in the commercial world can't bombard me with "GOTOs considered harmful" 
or, as Bob Lidral suggested "pointers considered harmful."

I don't make it a habit of using pointers, but by golly when I need one, 
they are sure handy and I resent the theorists, who for the sake of 
meeting their publish or perish goals, espouse stuff that may sound good 
on paper but puts a crimp on those of us who have to earn a living by 
achieving real results.

Also, the potential for dangling
> pointers is not unique to PL/I.   C and C++ also have this problem.  It is
> a possible concern in any language that supports pointers, though some
> languages have taken steps, such as those you mention in your reply,
> to prevent such things.
> 
> Don Dobbs remark about guns, knives, etc. is noteworthy.   Some languages
> such as Java have eliminated the issue of pointers from the immediate concern
> of the programmers.  This also introduces a whole new set of concerns.  Python
> makes every declaration dependent on indirection.   This is a good idea, but
> creates an overhead not tolerable for some circumstances.
> 
> So, it is not a good idea to entirely eliminate the capability for indirection.
> However,
> because this is often the most difficult source of errors to debug, and because
> it
> is so easy to create such errors, the combination of language design and
> compiler
> design ought to go a little further to reduce the frequency of them.
> 
> Tom suggests that one could "extend the compiler to issue an access violation in
> the above case."  Some compilers for some languages do just that.   PL/I
> compilers
> are not as dismally bad as C compilers (and some C++ compilers) in failing to
> warn (yes warn, not mollycoddle) the programmer of a possible access violation.
> I think Tom's idea is actually a very good one.
> 
> Richard Riehle
> 
> 
0
donaldldobbs (108)
1/6/2006 11:01:37 PM
adaworks@sbcglobal.net wrote:
> In software development tools, every benefit seems to have a corresponding
> liability.   You suggest that "add-in" is a bad thing.  Some would disagree that
> this simply means the language is flexible enough to support extension.   Since
> the I/O code is written in the underlying language, the interconnection is
> usually
> quite good.  For most modern languages this is not a problem.
> 

The problem is, for example, C's "buffer overflow" propensity.  This 
simply [usually] won't happen in PL/I because the I/O routines are 
passed a descriptor with the length of the buffer.  It also simplifies 
error handling for things like the ONCHAR builtin and pseudovariable.

After I posted, I gave this some thought.  It would be fairly easy to 
provide the best of both worlds.  I would assume many compilers do as 
I'm doing, [except The OS Optimizing compiler with ENVIRONMENT(TOTAL) ]: 
I route all I/O through a driver procedure that handles implicit opens 
and other stuff common to all statements, and then calls, for example 
READ or PUT.  These in turn call O/S code to do the actual I/O.  Most 
compilers also parse the ENVIRONMENT and OPTIONS strings [as I do].

If these strings were passed either unparsed or tokenized they could 
provide input to a generalized "device-dependent" layer.  Coding, for 
example, something like ENVIROMNENT( DD(xyz) ) could cause a DLL named 
xyz.dll to be loaded when the file is opened.  This DLL would have entry 
points for GET, PUT, READ, WRITE, or whatever, the way OS device drivers 
are writen.  In this way a user could code and use any kind of 
device-specific libraries he wanted without touching the compiler, using 
standard I/O statements.
> 
>>As far as supporting different devices, the ENVIRONMENT option and the
>>OPTIONS keyword allow the language to be easily extended to support any
>>device you want.  PL/I(F) used to support QTAM, not all that different
>>from TCP, and PL/I has been used for realtime control of specialized
>>devices.

Yes.

0
Peter_Flass (956)
1/6/2006 11:07:52 PM
adaworks@sbcglobal.net wrote:
> Most people who specialize in programming language design see the
> pointer design of PL/I as a bad thing.  From Sebesta's book on
> comparative programming languages:

Most people who specialize in programming language design seem to talk 
only among themselves.  Beginning with Pascal, they've come up with more 
and more exotic languages that no one uses in the real world.

0
Peter_Flass (956)
1/6/2006 11:16:49 PM

Bob Lidral wrote:

> Tom Linden wrote:
> 
>> On Fri, 06 Jan 2006 18:01:46 GMT, <adaworks@sbcglobal.net> wrote:
>>
>>>
>>> [...]
>>>
>>> Consider the following problem with ALLOCATE.
>>>
>>>        DECLARE SUM FLOAT BASED (POINT);
>>>             ...
>>>        ALLOCATE SUM;
>>>
>>>               ...
>>>        ALLOCATE SUM;
>>
>>
>>
>> Again, while licit code, it is in error.   Do you really want the 
>> compiler
>> to correct the programmer's errors?  Either the programmer forgot to FREE
>> or he wanted CONTROLLED allocation, or he wanted a list of pointers, 
>> or ...
>>
> Actually, in the absence of more information about the code represented
> by the ellipsis, we can't determine whether the example is in error.
> Perhaps the intervening code contains references to SUM or POINT or
> invokes procedures that do.  Such code could be used to allocate
> successive entries in a list if the value of POINT were saved somewhere
> somewhere in the intervening code.  [Although I'm having a hard time
> thinking of anything useful to do with a list of FLOAT values with no
> further information associated with each.]
> 
>>>
>>> After the first dynamic allocation, the first object still exists.   
>>> Again,
>>> a modern PL/I compiler might provide a warning, but this was not
>>> true of earlier compilers.   We have a dangling object, not a dangling
>>> reference.   At least this simply consumes storage rather than creating
>>> a possible program error.
>>>
>>> [...]
>>>
>>> I don't think we can easily dismiss the concern by blaming mediocre  
>>> programmers.
>>> I have seen experience programmers make mistakes they might not have  
>>> made if
>>> they were completely on-their-game.   I have certainly made stupid  
>>> mistakes over
>>> the years, and still do from time to time.  Pointers are a source of  
>>> errors.
>>> Compilers
>>> need to at least warn the programmer about potential problems, or  
>>> prevent them
>>> from
>>> creating unsafe constructs, whenever they can detect those problems.
>>>
> I have a few favorite management, sales, and marketing misconceptions
> and you've just touched on one of them: that somehow cramming more work
> hours into a (short) time span increases the amount of work
> accomplished.  For example: working overtime increases productivity.
> Once a certain point is passed, exhaustion, foul temper, resentment,
> outside pressures (e.g.,  family), etc. cause loss of concentrarion,
> leading to "stupid" mistakes which can more than offset any possible
> increase in work output.  

I once reported to an aerospace project manager (one of the best I ever 
encountered) who was yanked from our project to take over development on 
one of the Saturn rocket stages because they were falling behind 
schedule.  When he got there he found that everyone was working a 48- to 
56-hour week "to catch up."  The first thing he did to get back on track 
was to cancel all overtime.  He then insisted that everyone actually 
work their 40 hours (less time at the water cooler, etc.) but no more 
than 40.  And guess what?  He got the project back on schedule.

Given the management and sales pressures on
> programmers, even good programmers should be expected to make some
> "stupid" mistakes now and then.

True, true.  But that's why we desk check, test, test, test, and then 
give it to QA.  The responsible programmers should not be penalized (by 
language restrictions) just because a few programmers are sloppy.  Of 
course, ultimately management is culpable when good code isn't produced.

> 
> I was going to list a few others of my favorite misconceptions, but
> you're already probably familiar with all of them; it not, see Dilbert.  
> :-)
> 
>>> Richard Riehle
> 
> 
> 
> Bob Lidral
> lidral  at  alum  dot  mit  dot  edu
> 
> 
0
donaldldobbs (108)
1/6/2006 11:19:49 PM
Richard Brady wrote:
> Bob Lidral wrote:
>> Donald L. Dobbs wrote:
>>
>>> While there may be some truth in what you say, maybe we should just 
>>> eliminate pointers altogether from all HLLs since they are so 
>>> danerous for unsuspecting programmers.
>>>
>> You may have something there.  How about writing a letter to CACM?  
>> You could title it "Pointers Considered Harmful".  :-)
>>
>>
>> Bob Lidral
>> lidral  at  alum  dot  mit  dot  edu
> I once worked with a fellow who removed all references to tables in 
> programs that he worked on because he thought programmers made too many 
> errors using tables.

Hi. Remember me? The one who said "Anonymous pointers were a mistake," 
in the first place?

That was "/anonymous/ pointers", folks. The only kind of pointer there 
was in PL/I until HANDLE was introduced by the OS/2 compiler, and which 
even C had the good sense to avoid. Remember them?

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/7/2006 2:25:47 AM
"Donald L. Dobbs" <donaldldobbs@cox.net> wrote in message
news:kCCvf.2755$eR.1588@fed1read03...
>
>
> In the 40 years that I have been using PL/I (I was part of a PL/I beta
> site in 1965) from mainframes to micros I have never had a memory leak
> or a dangling anything.  I don't consider myself an exceptional
> programmer skillwise -- just one who follows the rules and is very
> careful and deliberate when playing with fire (using pointers) in the
> same way I don't point a loaded gun at anyone.
>
It is clear that you are an experienced and careful programmer -- more than
a programmer, I suspect.   We have approximately the same number of
years in software, it seems.

I am not opposed to pointers.   And, Mr. Lidral's comment about "pointers
being harmful" would, if presented by someone of Dijkstra's stature, set
off another silly set of rulemaking similar to that we experienced after the
"Go To Considered Harmful" article of 1968.

Still, even though pointers are a useful tool, they also hold the potential for
doing harm to a program -- perhaps not in your hands, but in the hands
of someone else.   Sensible people will not point any gun, loaded or unloaded,
at another human.  Also, we restrict the availability of guns in certain
environments.
It is no longer good manners to carry a gun on a commercial airline flight -- 
probably
never was.

When there is a programming feature that has such potential for harm, and also
so
much difficulty in debugging ( I once had to deal with a C program that involved
four levels of pointer; a pointer to a pointer to a pointer to a pointer to an
object),
some help from the compiler and language rules is welcome, even only in the form
of warnings.

The code in my example, whatever the code might be in the ellipses, illustrates
the potential for a problem even though the programmers who frequent this
forum might be too professional to create such problems.   The fact is that
they can be created, and have created problems with programs in the past.

I really like Tom Linden's idea of how to check for this kind of error.
However,
I think it should be flagged as a warning, not a fatal error, since it may
sometimes
be the best way to solve a particular programming problem.

Incidentally, even though I am now a "pointy-headed academic" I have also earned
my living as a practicing programmer.   My role as an academic is relatively
recent.

Your note about not using pointers but welcoming their availability when you
need
them is also instructive.   Too often new programmers grab any feature they find
interesting and work their solution around it.   It was Maurice Wilkes who said,
"There is no problem in computer programming that cannot be solved by adding
yet another level of indirection."   Indirection, in his view, meant pointers.
I don't
know who said,  "There is no problem in computer programming that cannot be
made more complicated by adding yet another level of indirection."     Both
observations are probably true.

Also Mr. Lidral, the observes that weary or stressed programmers do
make mistakes. This suggests that, when the tools are available to help
prevent those mistakes, programming gets better.   This might be true.
Sometimes we misuse even the best tools, and create an entirely new
set of problems.   Sometimes we just need to learn to use the tools we
have with greater skill.

When it comes to programming languages, I come down on the side of languages
where the compiler writers can maximize the amount of information necessary
to determine the dependability of my program.   I used to enjoy Assembler, and
if I had the time for it, would still enjoy it.   But most programmers are
engaged
in developing applications.  The more help we can give them, the better for
everyone.

If a PL/I does provide the compiler writer with the ability to warn against
constructs
that might be problematic, then it should be done.   I know I appreciate the
information
about my potential mistakes when I am writing programs.

Richard Riehle


0
adaworks2 (748)
1/7/2006 3:51:15 AM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:cLCvf.74815$XC4.57064@twister.nyroc.rr.com...
>
> The problem is, for example, C's "buffer overflow" propensity.  This
> simply [usually] won't happen in PL/I because the I/O routines are
> passed a descriptor with the length of the buffer.  It also simplifies
> error handling for things like the ONCHAR builtin and pseudovariable.
>
In the case of C, there are more problems than the one you mentioned,
and it ought not to be used for anything that requires a high level of
dependability, given the alternatives now available.  However, your
observation is not true of all languages that decouple the I/O from
the language.

Richard Riehle


0
adaworks2 (748)
1/7/2006 3:54:48 AM
adaworks@sbcglobal.net wrote:
> "Donald L. Dobbs" <donaldldobbs@cox.net> wrote in message
> news:kCCvf.2755$eR.1588@fed1read03...
> 
>>
>>In the 40 years that I have been using PL/I (I was part of a PL/I beta
>>site in 1965) from mainframes to micros I have never had a memory leak
>>or a dangling anything.  I don't consider myself an exceptional
>>programmer skillwise -- just one who follows the rules and is very
>>careful and deliberate when playing with fire (using pointers) in the
>>same way I don't point a loaded gun at anyone.
>>
> 
> It is clear that you are an experienced and careful programmer -- more than
> a programmer, I suspect.   We have approximately the same number of
> years in software, it seems.
> 
> I am not opposed to pointers.   And, Mr. Lidral's comment about "pointers
> being harmful" would, if presented by someone of Dijkstra's stature, set
> off another silly set of rulemaking similar to that we experienced after the
> "Go To Considered Harmful" article of 1968.
> 
The title "GOTO Statement Considered Harmful" was applied by the editor of CACM 
to a letter to the editor, not a reviewed article, submitted by Edsgar W. 
Dijkstra.  Almost immediately, X Considered Harmful documents began to appear. 
There are even some entitled "Considered Harmful" Essays Considered Harmful or 
words to that effect.  At least one such appeared in SIGPLAN Notices about 
twenty years ago.  A Google search on "Considered Harmful" turns up some 
17,000,000 hits with Dijkstra's letter being number one and "Considered Harmful" 
Essays Considered Harmful being number two.  There are over 200,000 considered 
harmful hits involving pointers.  Nevertheless I, for one, will continue to use 
pointers and to paraphrase Knuth, I find them one of Computing's greatest treasures.
0
jjw (608)
1/7/2006 4:20:38 AM

adaworks@sbcglobal.net wrote:
> "Donald L. Dobbs" <donaldldobbs@cox.net> wrote in message
> news:kCCvf.2755$eR.1588@fed1read03...
> 
>>
>>In the 40 years that I have been using PL/I (I was part of a PL/I beta
>>site in 1965) from mainframes to micros I have never had a memory leak
>>or a dangling anything.  I don't consider myself an exceptional
>>programmer skillwise -- just one who follows the rules and is very
>>careful and deliberate when playing with fire (using pointers) in the
>>same way I don't point a loaded gun at anyone.
>>
> 
> It is clear that you are an experienced and careful programmer -- more than
> a programmer, I suspect.   We have approximately the same number of
> years in software, it seems.

Yes, more than a programmer.  While I have been coding since late 1962, 
more of my work schedule has been in technical and/or project management 
than in full-time coding.

> 
> I am not opposed to pointers.   And, Mr. Lidral's comment about "pointers
> being harmful" would, if presented by someone of Dijkstra's stature, set
> off another silly set of rulemaking similar to that we experienced after the
> "Go To Considered Harmful" article of 1968.
> 
> Still, even though pointers are a useful tool, they also hold the potential for
> doing harm to a program -- perhaps not in your hands, but in the hands
> of someone else.   Sensible people will not point any gun, loaded or unloaded,
> at another human.  Also, we restrict the availability of guns in certain
> environments.
> It is no longer good manners to carry a gun on a commercial airline flight -- 
> probably
> never was.
> 
> When there is a programming feature that has such potential for harm, and also
> so
> much difficulty in debugging ( I once had to deal with a C program that involved
> four levels of pointer; a pointer to a pointer to a pointer to a pointer to an
> object),
> some help from the compiler and language rules is welcome, even only in the form
> of warnings.
> 
> The code in my example, whatever the code might be in the ellipses, illustrates
> the potential for a problem even though the programmers who frequent this
> forum might be too professional to create such problems.   The fact is that
> they can be created, and have created problems with programs in the past.
> 
> I really like Tom Linden's idea of how to check for this kind of error.
> However,
> I think it should be flagged as a warning, not a fatal error, since it may
> sometimes
> be the best way to solve a particular programming problem.
> 
> Incidentally, even though I am now a "pointy-headed academic" I have also earned
> my living as a practicing programmer.   My role as an academic is relatively
> recent.

I was aware of that, and hoped that you would understand that I was 
referring to the Dijkstras and Hoares of the world and not you.

> 
> Your note about not using pointers but welcoming their availability when you
> need
> them is also instructive.   Too often new programmers grab any feature they find
> interesting and work their solution around it. 

When programming, I have the American Indian's approach to the 
environment in mind, and never venture beyond what is minimally 
necessary to achieve the desired result.  I am not an adventurous 
programmer who uses features just because they are cute.  This 
philosophy has served me so well that in my entire career I have never 
had to resort to the use of a debugger to achieve perfection in my code. 
  But I have had to use debuggers frequently when saddled with cleanup 
and/or maintenance of someone else's software when I was left "holding 
the bag."  I guess I am naive, but I have never been able to fully 
comprehend why programs end up being so buggy -- well, with C and C++ I 
understand.  But with the other HLLs such as Fortran, Cobol, and PL/I 
there is absolutely no excuse for not producing perfection (which, by 
the way, in the minimum acceptable standard in coding).

   It was Maurice Wilkes who said,
> "There is no problem in computer programming that cannot be solved by adding
> yet another level of indirection."   Indirection, in his view, meant pointers.
> I don't
> know who said,  "There is no problem in computer programming that cannot be
> made more complicated by adding yet another level of indirection."     Both
> observations are probably true.
> 
> Also Mr. Lidral, the observes that weary or stressed programmers do
> make mistakes. 

This is a management problem that should not be laid at the feet of the 
competent programmer.  I've been on both sides of that fence.  Managers 
of programmers should be former programmers with management skills. 
While better tools are certainly an aid, better training should be part 
of the solution, as well.

I am aware that most airlines (mainly for fuel economy purposes) force 
their pilots to switch to autopilot as soon as the plane reaches 400 
feet altitude.  The plane stays on autopilot until final approach.  Nice 
tool, saves fuel, and probably gives the passengers a smoother ride. 
BUT, the pilots are losing some of their skills because they are not 
getting enough "stick time."  The simulators give them a chance to make 
up for some of this, but not completely.  I would not like to see 
'professional' programmers get so used to tools (crutches) that they 
can't program without them.

This suggests that, when the tools are available to help
> prevent those mistakes, programming gets better.   This might be true.
> Sometimes we misuse even the best tools, and create an entirely new
> set of problems.   Sometimes we just need to learn to use the tools we
> have with greater skill.
> 
> When it comes to programming languages, I come down on the side of languages
> where the compiler writers can maximize the amount of information necessary
> to determine the dependability of my program.   I used to enjoy Assembler, and
> if I had the time for it, would still enjoy it.   But most programmers are
> engaged
> in developing applications.  The more help we can give them, the better for
> everyone.
> 
> If a PL/I does provide the compiler writer with the ability to warn against
> constructs
> that might be problematic, then it should be done. 

No objection to warnings, provided it doesn't bloat the compiler too 
much and is done well enough to minimize false positives and false 
negatives.  [Tom L. is smart enough to figure all that out -- I'm not...]

   I know I appreciate the
> information
> about my potential mistakes when I am writing programs.
> 
> Richard Riehle
> 
> 
0
donaldldobbs (108)
1/7/2006 4:48:10 AM

James J. Weinkam wrote:

> adaworks@sbcglobal.net wrote:
> 
>> "Donald L. Dobbs" <donaldldobbs@cox.net> wrote in message
>> news:kCCvf.2755$eR.1588@fed1read03...
>>
>>>
>>> In the 40 years that I have been using PL/I (I was part of a PL/I beta
>>> site in 1965) from mainframes to micros I have never had a memory leak
>>> or a dangling anything.  I don't consider myself an exceptional
>>> programmer skillwise -- just one who follows the rules and is very
>>> careful and deliberate when playing with fire (using pointers) in the
>>> same way I don't point a loaded gun at anyone.
>>>
>>
>> It is clear that you are an experienced and careful programmer -- more 
>> than
>> a programmer, I suspect.   We have approximately the same number of
>> years in software, it seems.
>>
>> I am not opposed to pointers.   And, Mr. Lidral's comment about "pointers
>> being harmful" would, if presented by someone of Dijkstra's stature, set
>> off another silly set of rulemaking similar to that we experienced 
>> after the
>> "Go To Considered Harmful" article of 1968.
>>
> The title "GOTO Statement Considered Harmful" was applied by the editor 
> of CACM to a letter to the editor, not a reviewed article, submitted by 
> Edsgar W. Dijkstra.  Almost immediately, X Considered Harmful documents 
> began to appear. There are even some entitled "Considered Harmful" 
> Essays Considered Harmful or words to that effect.  At least one such 
> appeared in SIGPLAN Notices about twenty years ago.  A Google search on 
> "Considered Harmful" turns up some 17,000,000 hits with Dijkstra's 
> letter being number one and "Considered Harmful" Essays Considered 
> Harmful being number two.  There are over 200,000 considered harmful 
> hits involving pointers.  Nevertheless I, for one, will continue to use 
> pointers and to paraphrase Knuth, I find them one of Computing's 
> greatest treasures.

I could never understand the firestorm that that letter created because 
at the time PL/I already existed and with it's IF THEN .. ELSE and DO 
UNTIL and DO WHILE constructs GOTOs were becoming a dying breed anyway. 
  Some said the GOTO was necessary to escape from an ON ERROR BEGIN .. 
END block, but as has been pointed out earlier in this discussion the 
better approach is to set a flag within the block and let the END 
statment revert flow back to the main stream.  Then deal with it there.

And, by the way, the GOTO is not the harmful part of the picture.  It's 
the "come from" that is the problem.  The GOTO is very explicit as to 
the destination label.  But in a large program sprinkled with GOTOs, at 
any given label, you have no clue as to how many GOTOs have targeted it, 
or where they are located in the program.  I once wrote a special cross 
reference program for a client who used a dialect of BASIC that had no 
IF THEN ELSE constructs so naturally the code was littered with GOTOs. 
The cross reference program listed all of the statment numbers of all 
the GOTOs to any given target label.  This feature was of tremendous 
value to the spaghetti programmers and especially to the others who 
eventually had to maintain the spaghetti.

0
donaldldobbs (108)
1/7/2006 5:13:25 AM
John W. Kennedy wrote:
> That was "/anonymous/ pointers", folks. The only kind of pointer there 
> was in PL/I until HANDLE was introduced by the OS/2 compiler, and which 
> even C had the good sense to avoid. Remember them?
> 

Yes, I *love* code like a = (struct a*)( (char *)p + 2 );

ASll this casting garbage is pointless junk due to typed pointers/  if p 
is a pointer, p=p+1 should point to the next *byte*, every time.

0
Peter_Flass (956)
1/7/2006 1:16:08 PM
Peter Flass wrote:
> John W. Kennedy wrote:
>> That was "/anonymous/ pointers", folks. The only kind of pointer there 
>> was in PL/I until HANDLE was introduced by the OS/2 compiler, and 
>> which even C had the good sense to avoid. Remember them?
>>
> 
> Yes, I *love* code like a = (struct a*)( (char *)p + 2 );
> 
> ASll this casting garbage is pointless junk due to typed pointers/  if p 
> is a pointer, p=p+1 should point to the next *byte*, every time.

Flat-out wrong. "Byte" is an implementation concept.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/7/2006 3:22:33 PM
Donald L. Dobbs wrote:
> I could never understand the firestorm that that letter created because 
> at the time PL/I already existed and with it's IF THEN .. ELSE and DO 
> UNTIL and DO WHILE constructs GOTOs were becoming a dying breed anyway. 
>  Some said the GOTO was necessary to escape from an ON ERROR BEGIN .. 
> END block, but as has been pointed out earlier in this discussion the 
> better approach is to set a flag within the block and let the END 
> statment revert flow back to the main stream.  Then deal with it there.

Not so. You /must/ GOTO out of ON ERROR.

-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
1/7/2006 3:23:39 PM
Peter Flass wrote:
> John W. Kennedy wrote:
> 
>> That was "/anonymous/ pointers", folks. The only kind of pointer there 
>> was in PL/I until HANDLE was introduced by the OS/2 compiler, and 
>> which even C had the good sense to avoid. Remember them?
>>
> 
> Yes, I *love* code like a = (struct a*)( (char *)p + 2 );
> 
> ASll this casting garbage is pointless junk due to typed pointers/  if p 
> is a pointer, p=p+1 should point to the next *byte*, every time.
> 

Actually, it looks like casting garbage due to poor design.  And writing 
bad code is possible in almost any language.

Why do you think that p++ should always point to the next "byte", what 
ever that is.

LR
0
lruss (582)
1/7/2006 5:34:59 PM
Robin recently sent me a direct message with some points
about my remarks regarding the decoupling of I/O from
the core language.   It seems appropriate that I include my
response in the forum where others can comment, if they
wish.

================================================
From: "Robin Vowels" <robin_v@bigpond.com>
To: <adaworks@sbcglobal.net>
> >
> > It also reduces the number of reserved words in the language.
>
> Actually, it increases them.
> Thankfully, PL/I does not have reserved words.
> [It increases the number of reserved words because the
> library procedure names become defacto reserved words.]
>
As you know, much of my experience includes Ada.  In Ada, when
the I/O is separate from the core language, but implemented in that
language, the library names do not become de facto reserved words.
This is due to the rather strict scope and visibility rules defined for
the language.

This is not necessarily true of other languages that decouple I/O
from the core language.
> >
> > I have not noticed any degradation of reliability due to the decoupling of
> > I/O from the core language specification.
>
> Reliability is not the issue,.  The issue is that the compiler can't
> give informative error messages specific to I/O tasks when
> the I/O is done by procedure calls (which look like ... well,
> common or garden procedure calls).
>
Again, this is not a universal truth.  Some languages do quite well
giving such errors.  It is not always a function of language, but is
also a matter of how well a compiler is designed.

In some cases, the libraries are standard libraries.  They are not part
of the core language, but they are part of the language standard.  This
means the compiler developers can include a thorough and in-depth
evaluation of the procedure calls and report on violations at many
different levels.

This approach provides a separation of concerns that has demonstrated
itself to work quite well -- certainly as well as the alternative -- when the
I/O libraries are part of the language standard, but not part of the core
language.

When designing a language, one has to decide what will be part of the
core language and what can be decoupled from that language.  Different
design approaches are likely to be taken.   How big should a language
be before some things are decoupled from it?   Can we keep the core
language small and implement everything else in standard libraries?  Is
the complexity of the core language sufficiently minimal so that everything
can be easily included?    What is the impact on portability?

In modern computing, the class construct and the abstract data type have
become important in the support of modularity.   Language designers
and compiler designers, in contemporary computing, have taken the
benefits of modularity to heart and have found that focus on the language
design, independently of the standard libraries, has had the benefit of
improved performance and  portability.  Perhaps this would not be the
case with PL/I.  It seems true for many other modern languages.

Scripting languages have taken a different approach.  Python, Perl, Ruby,
and many others have included I/O, to good effect.   Functional languages
have also successfully included I/O.  However, even in the
aforementioned languages, it frequently becomes useful to have separate
specialized I/O libraries.   I don't think I want device drivers for every
kind of device built in to such languages.    Of course, this is an OS issue,
in many circumstances, and standard interfaces would be a blessing.

I am not condemming the PL/I approach.  I was simply commenting that
language language designers have been moving in a different direction for
quite some time.  And the direction they have taken has proven itself to
work as effectively as the alternative.

In the particular case of standard libraries, compiler writers have been able
to include all the necessary and useful diagnostics that they would have
included in a language where all the I/O is integrated into the core
language.   From the perspective of those designers, this reduces the
number of defects in the core compiler, and makes it possible to test
the libraries with a well-formed compiler without having to worry about
some strange behavior from that compiler.   That is, they get one thing
working, test it thoroughly, then move on to get something else working
using the thing they already know does work as intended.   Yes, this can
be done using the PL/I approach.   It is simply a difference in design
philosophy.

Richard Riehle


0
adaworks2 (748)
1/7/2006 5:53:29 PM
Donald L. Dobbs wrote:
> 
> 
> James J. Weinkam wrote:
> 
>> adaworks@sbcglobal.net wrote:
>>
>>> "Donald L. Dobbs" <donaldldobbs@cox.net> wrote in message
>>> news:kCCvf.2755$eR.1588@fed1read03...
>>>
>>>>
>>>> In the 40 years that I have been using PL/I (I was part of a PL/I beta
>>>> site in 1965) from mainframes to micros I have never had a memory leak
>>>> or a dangling anything.  I don't consider myself an exceptional
>>>> programmer skillwise -- just one who follows the rules and is very
>>>> careful and deliberate when playing with fire (using pointers) in the
>>>> same way I don't point a loaded gun at anyone.
>>>>
>>>
>>> It is clear that you are an experienced and careful programmer -- 
>>> more than
>>> a programmer, I suspect.   We have approximately the same number of
>>> years in software, it seems.
>>>
>>> I am not opposed to pointers.   And, Mr. Lidral's comment about 
>>> "pointers
>>> being harmful" would, if presented by someone of Dijkstra's stature, set
>>> off another silly set of rulemaking similar to that we experienced 
>>> after the
>>> "Go To Considered Harmful" article of 1968.
>>>
>> The title "GOTO Statement Considered Harmful" was applied by the 
>> editor of CACM to a letter to the editor, not a reviewed article, 
>> submitted by Edsgar W. Dijkstra.  Almost immediately, X Considered 
>> Harmful documents began to appear. There are even some entitled 
>> "Considered Harmful" Essays Considered Harmful or words to that 
>> effect.  At least one such appeared in SIGPLAN Notices about twenty 
>> years ago.  A Google search on "Considered Harmful" turns up some 
>> 17,000,000 hits with Dijkstra's letter being number one and 
>> "Considered Harmful" Essays Considered Harmful being number two.  
>> There are over 200,000 considered harmful hits involving pointers.  
>> Nevertheless I, for one, will continue to use pointers and to 
>> paraphrase Knuth, I find them one of Computing's greatest treasures.
> 
> 
> I could never understand the firestorm that that letter created because 
> at the time PL/I already existed and with it's IF THEN .. ELSE and DO 
> UNTIL and DO WHILE constructs GOTOs were becoming a dying breed anyway. 
>  Some said the GOTO was necessary to escape from an ON ERROR BEGIN .. 
> END block, but as has been pointed out earlier in this discussion the 
> better approach is to set a flag within the block and let the END 
> statment revert flow back to the main stream.  Then deal with it there.

This won't work.  Upon normal return from an ERROR on unit the FINISH condition 
is raised.  If there is no FINISH on unit of the FINISH on unit does a normal 
return the program is terminated.  Thus you have to use an abnormal return 
(GOTO) somewhere.  Also, setting a bit and letting the "main stream" deal with 
"it" means that at each and every place where something could happen that raises 
ERROR, IF THEN logic would have to be inserted to "deal with it".  No thanks.
> 
> And, by the way, the GOTO is not the harmful part of the picture.  It's 
> the "come from" that is the problem.  

There have been articles (tongue in cheek to be sure) proposing a COME FROM 
statement.

The GOTO is very explicit as to
> the destination label.  But in a large program sprinkled with GOTOs, at 
> any given label, you have no clue as to how many GOTOs have targeted it, 
> or where they are located in the program.  I once wrote a special cross 
> reference program for a client who used a dialect of BASIC that had no 
> IF THEN ELSE constructs so naturally the code was littered with GOTOs. 
> The cross reference program listed all of the statment numbers of all 
> the GOTOs to any given target label.  This feature was of tremendous 
> value to the spaghetti programmers and especially to the others who 
> eventually had to maintain the spaghetti.
> 
0
jjw (608)
1/7/2006 7:57:40 PM
LR wrote:
> Peter Flass wrote:
> 
>> John W. Kennedy wrote:
>>
>>> That was "/anonymous/ pointers", folks. The only kind of pointer 
>>> there was in PL/I until HANDLE was introduced by the OS/2 compiler, 
>>> and which even C had the good sense to avoid. Remember them?
>>>
>>
>> Yes, I *love* code like a = (struct a*)( (char *)p + 2 );
>>
>> ASll this casting garbage is pointless junk due to typed pointers/  if 
>> p is a pointer, p=p+1 should point to the next *byte*, every time.
>>
> 
> Actually, it looks like casting garbage due to poor design.  And writing 
> bad code is possible in almost any language.
> 
> Why do you think that p++ should always point to the next "byte", what 
> ever that is.
> 
So that I, as someone picking up a program, don't have to worry whether 
this a pointer to an int, a struct, or whatever?  If I want it to point 
somewhere else, I'll say so: p+=sizeof(struct a), p+=sizeof int, or 
whatever.  I do a lot of "do-it-yourself" memory management, and do a 
lot of arithmetic with pointers that address storage in a heap that 
contains lots of different structures, and I don't want to have to keep 
casting the $#$^# pointers in order to use them.

0
Peter_Flass (956)
1/7/2006 8:53:03 PM
<adaworks@sbcglobal.net> wrote in message
news:16kvf.50217$q%.39586@newssvr12.news.prodigy.com...
>
> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
> news:iAPuf.50632$XJ5.16483@twister.nyroc.rr.com...
> >
> > To each his own, but I *strongly* disagree that this is desirable.  It's
> > a holdover from C, which, with its minimalist approach would allow
> > programs to be linked without any I/O at all.
> >
> I began my computing career using languages that had all th I/O built-in.
> It took a little while to get used to the idea of using languages in which
> I/O is implemented using separate libraries.
>
> Incidentally, this did not originate with C, but it certainly has been
> popularized
> by C.   I am no fan of C.   I dislike it, for the most part.  I also don't
like
> C++ for anything important or where reliability is a desired outcome.
> >
> > One of the strengths of PL/I is that the I/O is part of the language and
> > not an "add-in", so it's much more integrated with the compiled code
> > than libraries usually are or can be.  The code is still implemented via
> > libraries, it's the degree of interconnection that's important,
> >
> In software development tools, every benefit seems to have a corresponding
> liability.   You suggest that "add-in" is a bad thing.  Some would disagree
that
> this simply means the language is flexible enough to support extension.
Since
> the I/O code is written in the underlying language, the interconnection is
> usually
> quite good.  For most modern languages this is not a problem.

It's a serious problem in C.


0
robin_v (2737)
1/7/2006 9:12:40 PM
"Donald L. Dobbs" <donaldldobbs@cox.net> wrote in message
news:U2Ivf.2923$eR.1683@fed1read03...
> I could never understand the firestorm that that letter created because
> at the time PL/I already existed and with it's IF THEN .. ELSE and DO
> UNTIL and DO WHILE constructs GOTOs were becoming a dying breed anyway.
>   Some said the GOTO was necessary to escape from an ON ERROR BEGIN ..
> END block, but as has been pointed out earlier in this discussion the
> better approach is to set a flag within the block and let the END
> statment revert flow back to the main stream.  Then deal with it there.

That isn't universally true.  For some pl/i conditions the normal action
is to raise the ERROR condition, and thus if continuation is desired,
a GO TO must be executed.


0
robin_v (2737)
1/7/2006 9:12:41 PM
From: <adaworks@sbcglobal.net>
Sent: Friday, January 06, 2006 12:55 PM
> "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
> news:iAPuf.50632$XJ5.16483@twister.nyroc.rr.com...
> >
> > To each his own, but I *strongly* disagree that this is desirable.  It's
> > a holdover from C, which, with its minimalist approach would allow
> > programs to be linked without any I/O at all.
> >
> I began my computing career using languages that had all th I/O built-in.
> It took a little while to get used to the idea of using languages in which
> I/O is implemented using separate libraries.
>
> Incidentally, this did not originate with C, but it certainly has been
> popularized
> by C.   I am no fan of C.   I dislike it, for the most part.  I also don't
like
> C++ for anything important or where reliability is a desired outcome.
> >
> > One of the strengths of PL/I is that the I/O is part of the language and
> > not an "add-in", so it's much more integrated with the compiled code
> > than libraries usually are or can be.  The code is still implemented via
> > libraries, it's the degree of interconnection that's important,
> >
> In software development tools, every benefit seems to have a corresponding
> liability.   You suggest that "add-in" is a bad thing.  Some would disagree
that
> this simply means the language is flexible enough to support extension.
> Since the I/O code is written in the underlying language, the interconnection
> is usually quite good.  For most modern languages this is not a problem.
>
> It also reduces the number of reserved words in the language.

Actually, it increases them.
Thankfully, PL/I does not have reserved words.
[It increases the number of reserved words because the
library procedure names become defacto reserved words.]

>  OK, one might
> way that the presence of reserved words (and keywords) increases the ability
> of the compiler to detect errors.   That is true for compilers designed in
that
> way.  It is not the only truth, though.  I have worked with languages that
> are highly reliable where the I/O libraries are written separately.
>
> I have not noticed any degradation of reliability due to the decoupling of
> I/O from the core language specification.

Reliability is not the issue,.  The issue is that the compiler can't
give informative error messages specific to I/O tasks when
the I/O is done by procedure calls (which look like ... well,
common or garden procedure calls).

>   Further, it this were as horrid
> as some suggest, it would have lost credibility a long time ago.  Then again,
> people still insist on using C and C++, so that fact that something is horrid
> seems to have little effect on some people.


0
robin_v (2737)
1/7/2006 9:12:42 PM
Peter Flass wrote:
> LR wrote:
> 
>> Peter Flass wrote:
>>
>>> John W. Kennedy wrote:
>>>
>>>> That was "/anonymous/ pointers", folks. The only kind of pointer 
>>>> there was in PL/I until HANDLE was introduced by the OS/2 compiler, 
>>>> and which even C had the good sense to avoid. Remember them?
>>>>
>>>
>>> Yes, I *love* code like a = (struct a*)( (char *)p + 2 );
>>>
>>> ASll this casting garbage is pointless junk due to typed pointers/  
>>> if p is a pointer, p=p+1 should point to the next *byte*, every time.
>>>
>>
>> Actually, it looks like casting garbage due to poor design.  And 
>> writing bad code is possible in almost any language.
>>
>> Why do you think that p++ should always point to the next "byte", what 
>> ever that is.
>>
> So that I, as someone picking up a program, don't have to worry whether 
> this a pointer to an int, a struct, or whatever?  If I want it to point 
> somewhere else, I'll say so: p+=sizeof(struct a), p+=sizeof int, or 
> whatever.  

Ok, I understand. Thanks, although that seems like extra work to me, and 
perhaps also something of a maintainence problem if the thing that p is 
pointing to has its type changed.

 > I do a lot of "do-it-yourself" memory management, and do a
> lot of arithmetic with pointers that address storage in a heap that 
> contains lots of different structures, and I don't want to have to keep 
> casting the $#$^# pointers in order to use them.

I understand.  I think that most people would think of that as being a 
little less type safe, but to each their own.

A little off topic, but I was wondering if perhaps you'd prefer a 
language a little more like C++ (or maybe some other OO language) where 
you could probably write some kind of class that would give you the 
behavior you wanted.  Alternatively, perhaps you could write some 
function returning a pointer to get what you want?

Although, I think that "byte" thing might be a little tricky on some 
platforms.

Anyway, thanks for explaining.

LR


0
lruss (582)
1/7/2006 11:56:56 PM
robin wrote:
> "Donald L. Dobbs" <donaldldobbs@cox.net> wrote in message
> news:U2Ivf.2923$eR.1683@fed1read03...
> 
>>I could never understand the firestorm that that letter created because
>>at the time PL/I already existed and with it's IF THEN .. ELSE and DO
>>UNTIL and DO WHILE constructs GOTOs were becoming a dying breed anyway.
>>  Some said the GOTO was necessary to escape from an ON ERROR BEGIN ..
>>END block, but as has been pointed out earlier in this discussion the
>>better approach is to set a flag within the block and let the END
>>statment revert flow back to the main stream.  Then deal with it there.
> 
> 
> That isn't universally true.  For some pl/i conditions the normal action
> is to raise the ERROR condition, and thus if continuation is desired,
> a GO TO must be executed.
> 
> 
I probably misspoke when I said ERROR when I should have said ON 
condition ....      such as endfile and overflow, etc.

I will have to go back and check some of my programs written in D.R. 
PL/I-86.  It may be that it treats ERROR the same way as the other 
conditions.  If not, then I stand corrected.  But I do definitely recall 
that it works jim dandy for ENDFILE and ENDPAGE conditions.
0
donaldldobbs (108)
1/8/2006 6:51:44 AM
LR wrote:

> Peter Flass wrote:
> 
>> LR wrote:
>>
>>> Peter Flass wrote:
>>>
>>>> John W. Kennedy wrote:
>>>>
>>>>> That was "/anonymous/ pointers", folks. The only kind of pointer 
>>>>> there was in PL/I until HANDLE was introduced by the OS/2 compiler, 
>>>>> and which even C had the good sense to avoid. Remember them?
>>>>>
>>>>
>>>> Yes, I *love* code like a = (struct a*)( (char *)p + 2 );
>>>>
>>>> ASll this casting garbage is pointless junk due to typed pointers/  
>>>> if p is a pointer, p=p+1 should point to the next *byte*, every time.
>>>>
>>>
>>> Actually, it looks like casting garbage due to poor design.  And 
>>> writing bad code is possible in almost any language.
>>>
>>> Why do you think that p++ should always point to the next "byte", 
>>> what ever that is.
>>>
>> So that I, as someone picking up a program, don't have to worry 
>> whether this a pointer to an int, a struct, or whatever?  If I want it 
>> to point somewhere else, I'll say so: p+=sizeof(struct a), p+=sizeof 
>> int, or whatever.  
> 
> 
> Ok, I understand. Thanks, although that seems like extra work to me, and 
> perhaps also something of a maintainence problem if the thing that p is 
> pointing to has its type changed.

It's more work somewhere, whichever way you go.  My prefreence is the 
PL/I way, but I understand lots of folks prefer typed pointers.  I guess 
it's like chocolate vs. vanilla.

> 
>  > I do a lot of "do-it-yourself" memory management, and do a
> 
>> lot of arithmetic with pointers that address storage in a heap that 
>> contains lots of different structures, and I don't want to have to 
>> keep casting the $#$^# pointers in order to use them.
> 
> 
> I understand.  I think that most people would think of that as being a 
> little less type safe, but to each their own.

Right.

> 
> A little off topic, but I was wondering if perhaps you'd prefer a 
> language a little more like C++ (or maybe some other OO language) where 
> you could probably write some kind of class that would give you the 
> behavior you wanted.  Alternatively, perhaps you could write some 
> function returning a pointer to get what you want?
> 
> Although, I think that "byte" thing might be a little tricky on some 
> platforms.

Not necessarily.  Every platform has a way of addressing individual 
characters, so a pointer has to be able to point to a character.  There 
may (still) be word-addressed hardware where a pointer is a word address 
plus some way to point to a character within a word, but it's all the 
same.  Pointer arithmetic should be able to handle whatever you throw at it.

> 
> Anyway, thanks for explaining.
> 
> LR
> 
> 

0
Peter_Flass (956)
1/8/2006 1:37:44 PM
<adaworks@sbcglobal.net> wrote in message
news:teTvf.52366$q%.22079@newssvr12.news.prodigy.com...
> Robin recently sent me a direct message with some points
> about my remarks regarding the decoupling of I/O from
> the core language.   It seems appropriate that I include my
> response in the forum where others can comment, if they
> wish.
>
> ================================================
> From: "Robin Vowels" <robin_v@bigpond.com>
> To: <adaworks@sbcglobal.net>
> > >
> > > It also reduces the number of reserved words in the language.
> >
> > Actually, it increases them.
> > Thankfully, PL/I does not have reserved words.
> > [It increases the number of reserved words because the
> > library procedure names become defacto reserved words.]
> >
> As you know, much of my experience includes Ada.  In Ada, when
> the I/O is separate from the core language, but implemented in that
> language, the library names do not become de facto reserved words.
> This is due to the rather strict scope and visibility rules defined for
> the language.

That is a drawback of that design.

> This is not necessarily true of other languages that decouple I/O
> from the core language.

> > > I have not noticed any degradation of reliability due to the decoupling of
> > > I/O from the core language specification.
> >
> > Reliability is not the issue,.  The issue is that the compiler can't
> > give informative error messages specific to I/O tasks when
> > the I/O is done by procedure calls (which look like ... well,
> > common or garden procedure calls).
> >
> Again, this is not a universal truth.  Some languages do quite well
> giving such errors.

They might do"quite well", but still fall short of the
help that the compiler can give when the I/O is
part of the language, not something that's tacked on
by way of procedure references.

>  It is not always a function of language, but is
> also a matter of how well a compiler is designed.
>
> In some cases, the libraries are standard libraries.  They are not part
> of the core language, but they are part of the language standard.  This
> means the compiler developers can include a thorough and in-depth
> evaluation of the procedure calls and report on violations at many
> different levels.
>
> This approach provides a separation of concerns that has demonstrated
> itself to work quite well -- certainly as well as the alternative -- when the
> I/O libraries are part of the language standard, but not part of the core
> language.

With the I/O defined in terms of procedure calls,
the compiler can't make a lot of sense as regards
diagnosing errors, and can only give messages related
to procedure calls, rather than to the specific I/O
constructs.
    With input and output specified by specific input and
output statements, however, the compiler can give
explicit messages for syntax errors that actually relate
to an input or output statement.
    I/O for Algol 60 was typically implemented as procedure
calls, and as such was a real mess.  Likewise for C, although
that's even messier.

> When designing a language, one has to decide what will be part of the
> core language and what can be decoupled from that language.  Different
> design approaches are likely to be taken.   How big should a language
> be before some things are decoupled from it?   Can we keep the core
> language small and implement everything else in standard libraries?  Is
> the complexity of the core language sufficiently minimal so that everything
> can be easily included?    What is the impact on portability?

I/O is one of the absolutely essential components of any
language.  As such, it should be part of the language.

> In modern computing, the class construct and the abstract data type have
> become important in the support of modularity.   Language designers
> and compiler designers, in contemporary computing, have taken the
> benefits of modularity to heart and have found that focus on the language
> design, independently of the standard libraries, has had the benefit of
> improved performance and  portability.

PL/I I/O is portable full stop.

>  Perhaps this would not be the
> case with PL/I.  It seems true for many other modern languages.
>
> Scripting languages have taken a different approach.  Python, Perl, Ruby,
> and many others have included I/O, to good effect.   Functional languages
> have also successfully included I/O.  However, even in the
> aforementioned languages, it frequently becomes useful to have separate
> specialized I/O libraries.   I don't think I want device drivers for every
> kind of device built in to such languages.

Nor it it necessary.
The I/O commands of PL/I, for example, are independent of the actual
device.

>    Of course, this is an OS issue,
> in many circumstances, and standard interfaces would be a blessing.
>
> I am not condemming the PL/I approach.  I was simply commenting that
> language language designers have been moving in a different direction for
> quite some time.  And the direction they have taken has proven itself to
> work as effectively as the alternative.

Unfortunately, that is not the case.

> In the particular case of standard libraries, compiler writers have been able
> to include all the necessary and useful diagnostics that they would have
> included in a language where all the I/O is integrated into the core
> language.

Take C, for example.  Formatted I/O.
The format specification is not processed at compile time.
It's left to the library.  If there's anything wrong with the
correspondence between data item and format item,
it's not picked up until run time, if it's detected at all.
As a consequence, some errors are not detected at all.

>   From the perspective of those designers, this reduces the
> number of defects in the core compiler,

But it doesn't reduce the number of defects in the whole
system.

> and makes it possible to test
> the libraries with a well-formed compiler without having to worry about
> some strange behavior from that compiler.   That is, they get one thing
> working, test it thoroughly, then move on to get something else working
> using the thing they already know does work as intended.

That is how one would build any compiler, namely,
to get one thing working, and then move onto the next.

>   Yes, this can
> be done using the PL/I approach.   It is simply a difference in design
> philosophy.

But it is a demonstrably inferior approach.


0
robin_v (2737)
4/21/2006 3:21:42 PM
I am not sure how much experience you have with languages where
the IO is decoupled from the core language.

You have mentioned C several times.

My experience of decoupled libraries, especially in Ada and
Eiffel, is quite different from yours.   In particular, Ada's package
design ensures that the compiler provides diagonostics as good
as any I have gotten in languages where the IO is intrinsic to the
language.

This is, in part, because Ada is explicitly designed to maximize the
amount of error-checking as early in the development process as
possible.

The package model ensures that every package facility referenced in
some other package must have compiled correctly prior to its invocation
in some other package.   This is a kind of building-block approach so the
IO facilities are created from primitives that open the way for more
kinds of IO routines.

You may not like this approach, but it is every bit as efficient, as 
maintainable,
and as effective as the alternative.

Richard Riehle



"robin" <robin_v@bigpond.com> wrote in message 
news:aM62g.12017$vy1.9304@news-server.bigpond.net.au...
> <adaworks@sbcglobal.net> wrote in message
> news:teTvf.52366$q%.22079@newssvr12.news.prodigy.com...
>> Robin recently sent me a direct message with some points
>> about my remarks regarding the decoupling of I/O from
>> the core language.   It seems appropriate that I include my
>> response in the forum where others can comment, if they
>> wish.
>>
>> ================================================
>> From: "Robin Vowels" <robin_v@bigpond.com>
>> To: <adaworks@sbcglobal.net>
>> > >
>> > > It also reduces the number of reserved words in the language.
>> >
>> > Actually, it increases them.
>> > Thankfully, PL/I does not have reserved words.
>> > [It increases the number of reserved words because the
>> > library procedure names become defacto reserved words.]
>> >
>> As you know, much of my experience includes Ada.  In Ada, when
>> the I/O is separate from the core language, but implemented in that
>> language, the library names do not become de facto reserved words.
>> This is due to the rather strict scope and visibility rules defined for
>> the language.
>
> That is a drawback of that design.
>
>> This is not necessarily true of other languages that decouple I/O
>> from the core language.
>
>> > > I have not noticed any degradation of reliability due to the decoupling 
>> > > of
>> > > I/O from the core language specification.
>> >
>> > Reliability is not the issue,.  The issue is that the compiler can't
>> > give informative error messages specific to I/O tasks when
>> > the I/O is done by procedure calls (which look like ... well,
>> > common or garden procedure calls).
>> >
>> Again, this is not a universal truth.  Some languages do quite well
>> giving such errors.
>
> They might do"quite well", but still fall short of the
> help that the compiler can give when the I/O is
> part of the language, not something that's tacked on
> by way of procedure references.
>
>>  It is not always a function of language, but is
>> also a matter of how well a compiler is designed.
>>
>> In some cases, the libraries are standard libraries.  They are not part
>> of the core language, but they are part of the language standard.  This
>> means the compiler developers can include a thorough and in-depth
>> evaluation of the procedure calls and report on violations at many
>> different levels.
>>
>> This approach provides a separation of concerns that has demonstrated
>> itself to work quite well -- certainly as well as the alternative -- when the
>> I/O libraries are part of the language standard, but not part of the core
>> language.
>
> With the I/O defined in terms of procedure calls,
> the compiler can't make a lot of sense as regards
> diagnosing errors, and can only give messages related
> to procedure calls, rather than to the specific I/O
> constructs.
>    With input and output specified by specific input and
> output statements, however, the compiler can give
> explicit messages for syntax errors that actually relate
> to an input or output statement.
>    I/O for Algol 60 was typically implemented as procedure
> calls, and as such was a real mess.  Likewise for C, although
> that's even messier.
>
>> When designing a language, one has to decide what will be part of the
>> core language and what can be decoupled from that language.  Different
>> design approaches are likely to be taken.   How big should a language
>> be before some things are decoupled from it?   Can we keep the core
>> language small and implement everything else in standard libraries?  Is
>> the complexity of the core language sufficiently minimal so that everything
>> can be easily included?    What is the impact on portability?
>
> I/O is one of the absolutely essential components of any
> language.  As such, it should be part of the language.
>
>> In modern computing, the class construct and the abstract data type have
>> become important in the support of modularity.   Language designers
>> and compiler designers, in contemporary computing, have taken the
>> benefits of modularity to heart and have found that focus on the language
>> design, independently of the standard libraries, has had the benefit of
>> improved performance and  portability.
>
> PL/I I/O is portable full stop.
>
>>  Perhaps this would not be the
>> case with PL/I.  It seems true for many other modern languages.
>>
>> Scripting languages have taken a different approach.  Python, Perl, Ruby,
>> and many others have included I/O, to good effect.   Functional languages
>> have also successfully included I/O.  However, even in the
>> aforementioned languages, it frequently becomes useful to have separate
>> specialized I/O libraries.   I don't think I want device drivers for every
>> kind of device built in to such languages.
>
> Nor it it necessary.
> The I/O commands of PL/I, for example, are independent of the actual
> device.
>
>>    Of course, this is an OS issue,
>> in many circumstances, and standard interfaces would be a blessing.
>>
>> I am not condemming the PL/I approach.  I was simply commenting that
>> language language designers have been moving in a different direction for
>> quite some time.  And the direction they have taken has proven itself to
>> work as effectively as the alternative.
>
> Unfortunately, that is not the case.
>
>> In the particular case of standard libraries, compiler writers have been able
>> to include all the necessary and useful diagnostics that they would have
>> included in a language where all the I/O is integrated into the core
>> language.
>
> Take C, for example.  Formatted I/O.
> The format specification is not processed at compile time.
> It's left to the library.  If there's anything wrong with the
> correspondence between data item and format item,
> it's not picked up until run time, if it's detected at all.
> As a consequence, some errors are not detected at all.
>
>>   From the perspective of those designers, this reduces the
>> number of defects in the core compiler,
>
> But it doesn't reduce the number of defects in the whole
> system.
>
>> and makes it possible to test
>> the libraries with a well-formed compiler without having to worry about
>> some strange behavior from that compiler.   That is, they get one thing
>> working, test it thoroughly, then move on to get something else working
>> using the thing they already know does work as intended.
>
> That is how one would build any compiler, namely,
> to get one thing working, and then move onto the next.
>
>>   Yes, this can
>> be done using the PL/I approach.   It is simply a difference in design
>> philosophy.
>
> But it is a demonstrably inferior approach.
>
> 


0
adaworks2 (748)
4/23/2006 12:55:27 AM
On Sat, 22 Apr 2006 17:55:27 -0700, <adaworks@sbcglobal.net> wrote:

> My experience of decoupled libraries, especially in Ada and
> Eiffel, is quite different from yours.   In particular, Ada's package
> design ensures that the compiler provides diagonostics as good
> as any I have gotten in languages where the IO is intrinsic to the
> language.
In PL/I there are three levels of diagnostics, those perfomed by the  
compiler,
those generated by the compiler and perfomed at execution time and those
performed by the runtime.
0
tom284 (1839)
4/23/2006 1:07:29 AM
"Tom Linden" <tom@kednos.com> wrote in message 
news:op.s8fr2rcvzgicya@hyrrokkin...
> On Sat, 22 Apr 2006 17:55:27 -0700, <adaworks@sbcglobal.net> wrote:
>
>> My experience of decoupled libraries, especially in Ada and
>> Eiffel, is quite different from yours.   In particular, Ada's package
>> design ensures that the compiler provides diagonostics as good
>> as any I have gotten in languages where the IO is intrinsic to the
>> language.
> In PL/I there are three levels of diagnostics, those perfomed by the 
> compiler,
> those generated by the compiler and perfomed at execution time and those
> performed by the runtime.

No unlike some languages that have I/O libraries.   In particular, Ada does
stringent checking at compile time.   There is an underlying run-time
environment attached to an Ada program that carries out checks during
execution.   A compiler may also include other kinds of diagnostics, and
those used for weapon systems and other safety-critical software have
more levels of error checking and management.

Richard Riehle 


0
adaworks2 (748)
4/23/2006 5:50:09 AM
Reply:

Similar Artilces:

A Lange & Sohne Lange Double Split
A Lange & Sohne Lange Double Split - A Lange & Sohne Watches Discount A Lange & Sohne Lange Double Split: http://www.fashion163.com/A_Lange_Sohne_Lange_Double_Split.html Luxury Watches Lower Prices: http://www.fashion163.com/ Quality A Lange & Sohne Watches http://www.fashion163.com/a_lange_sohne.html We guarantee our A Lange & Sohne Lange Double Split and A Lange & Sohne Lange Double Split aren't just a simple imitation. We use the same fine materials and technology that the original does. Each A Lange & Sohne Lange Double Split produced is examined careful...

PL/SQL Web Toolkit (mod_plsql) white papers available
A new series of white papers on building applications with Oracle's PL/SQL Web Toolkit is now being published to the Enquery website. The first draft of the initial paper 'The mod_plsql Environment' has just been released -- your comments, criticisms, corrections, feedback, etc. are requested. The goals of this series of papers include: [_] Provide a simple but comprehensive primer on the PL/SQL Web Toolkit (mod_plsql). [_] Provide progressive examples so that developers familiar with SQL and PL/SQL can work proficiently in the mod_plsql environment. [_] Highlight b...

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

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

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

Reinforcement Learning Paper
That's the Reinforcement Learning (collaborative Q-learning) related paper: Kartoun U., Stern H., Edan Y. 2006. Human-Robot Collaborative Learning System for Inspection. IEEE International Conference on Systems, Man, and Cybernetics. Oct. 8 - Oct. 11, 2006, Taipei, Taiwan. Direct download: http://www.compactech.com/kartoun/articles/Kartoun_SMC_2006.pdf .... and a short video: http://www.compactech.com/forum/index.php?showtopic=171 Thanks! Uri. ...

1978 AC M paper on early history and characteristics of PL/1
http://portal.acm.org/citation.cfm?doid=800025.808389 Phil Burton ...

paper
This paper was removed from the SUGI 24 site, does someone has a copy (maybe you got it before its removal)? if yes, can you send me a copy to my email account? Thanks a lot. Data Mining at IMS Health, How We Turned a Mountain of Data into a Few Information-rich Molehills, Jerry Kagan and Paul Kallukaran. What year was SUGI 24? "joey m" <sasuser.joey.m@GMAIL.COM> wrote in message news:705bcd670904230853y2ac9d61ei114e2bcee4cc0cea@mail.gmail.com... > This paper was removed from the SUGI 24 site, does someone has a copy > (maybe > you got it before its removal)? if y...

Paper
I am searching for this paper: Costas J.P.; "Poisson, Shannon, and the Radio Amateur", Proc. IRE, vol 47, pp. 2058-2068, Dec 1959 I couldn't find it on the IEEE database. If someone has a copy, please send me email. Thanks -- --... ...-- Ramakrishnan ...

Paper
Any opinions on Epson Heavyweight Matte Paper for color photos? I love it for B/W, but before I buy more, I'd appreciate any opinions. TIA Joe Arnold "PhotoMan" <photoman@wfeca.net> wrote in message news:1tgqb.44713$un.27411@bignews6.bellsouth.net... > Any opinions on Epson Heavyweight Matte Paper for color photos? I love it > for B/W, but before I buy more, I'd appreciate any opinions. > TIA > Joe Arnold > > Two words: Love it!!!! IMHO better than glossy ...

lang
fortran ...

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

Submitted papers for the Conference: 489, Accepted papers: 158, From them 6 papers are also accepted to the WSEAS journals
STATISTICS in the WSEAS Conferences: A representative example from the conference in Istanbul Submitted papers for the Conference: 489 Accepted papers: 158 From them 6 papers are also accepted to the WSEAS journals See the following message ----- Original Message ----- From: "Metin Demiralp" <demiralp@be.itu.edu.tr> To: "Prof. Dr. Nikos Mastorakis" <mastor@hna.gr>; "Prof. Dr. Nikos E. Mastorakis" <mastor@wseas.org> Sent: Wednesday, November 28, 2007 4:32 AM Subject: WSEAS (Istanbul Manuscripts) Dear Prof. Mastorakis Tonight I have not ...

Web resources about - Paper on PL/I - comp.lang.pl1

Paper Soccer - Wikipedia, the free encyclopedia
This article is an orphan , as no other articles link to it . Please introduce links to this page from related articles ; suggestions may be ...

Defence white paper will reboot relationship with industry Minister Payne says
Defence white paper will reset relationship with industry

Oscars 2016 $327k gift bag includes breast lift, sex toy and $390 toilet paper
... Oscar. Two-ply would just never do for the world's top actors, so that's why the who's who of Hollywood will be gifted $390 luxury toilet paper ...

The white paper process has given us a tax debate without a debate
Of all the questionable claims in the tax debate, the biggest it's that it's been a debate.

Tax white paper: Treasury considers winding back superannuation concessions
The government is paying private consultants $440,000 to model the effects of tax changes in an exercise the head of the Treasury says shouldn't ...

I need this autonomous Lego paper airplane assembly factory right now
I don’t make paper airplanes as much as I used to, and I don’t play with Legos as much as I’d really love to. But I'd definitely want this mesmerizing ...

Valentine's Day Craft: Paper Fortune Cookies
... for Valentine’s Day! They're pretty easy to make and can also be used for a Chinese New Year celebration, wedding or baby shower favors. Paper ...

In Paper Of Record, Hagiography Begins
I keep telling you that if Marco Rubio gets the Republican presidential nomination he will absolutely win the general election, in large part ...

Call for Papers: IoT Data Management and Analytics
The Internet of Things (IoT) is rapidly emerging as a transformational paradigm with a multitude of products and services now available and being ...

Paper: Anti-E-Cigarette Policy Often Based On ‘Blind Faith’ In Poor Research
Paper: Anti-E-Cigarette Policy Often Based On ‘Blind Faith’ In Poor Research

Resources last updated: 2/11/2016 8:56:11 AM