Is there anybody out there who uses
IBM's PLI compiler for the AS/400?
Regards,
-----------------------------------------------------------------
Dipl.-Ing. Rudolf Wiesmayr Tel: +43 - 0732 / 7070 - 1720
Magistrat Linz, ADV/AE Fax: +43 - 0732 / 7070 - 1555
Gruberstrasse 40-42 mailto://Rudolf....@mag.linz.at
A-4041 Linz IBMMAIL: at3v...@ibmmail.com
------ http://www.linz.at <<<--- Digital City Linz, Austria -----
I once used it at a company that I worked for. There apparently weren't
too many other users.
Jack
The following header lines retained to affect attribution:
|Date: Fri, 17 Jan 1997 15:53:06 -0500
|Reply-To: "PL1 (language) discussions" <PL...@PACEVM.DAC.PACE.EDU>
|From: Peter Flass <fl...@LBDC.SENATE.STATE.NY.US>
|Subject: Re: Re[2]: Pl1 decompiler
|To: Multiple recipients of list PL1-L <PL...@PACEVM.DAC.PACE.EDU>
|On Fri, 17 Jan 1997, Randolph J. Herber wrote:
|> I did not claim nor did I intend to claim that decompilation is mysterious.
|> I did claim and I did intend to claim that it is difficult because much of
|> the information in the original source is destroyed in the compilation
|> process. Unless the executable format identifies what is instructions
|> and what is data, reliably making that determination is difficult and can
|> be impossible if the program uses function pointers or similar constructs.
|Interesting point though -- although decompilation in the general case is
|difficult and error-prone, in the specific case of a particular compiler
|it may be less so. Code generated by a compiler will fit specific
|patterns or templates for loops, procedure entry and exit, etc.
|Decompilation then becomes a pattern-recognition problem.
Pattern recognition frequently is difficult particularly for optimized
executables. In optimized executables, loops may be unrolled, the
strength of operators within loops may be reduced (e.g. multiplications
may be replaced by additions), loop static computations may be moved
out of loops, inlined functions may not be identifiable as inlined
fucntions, repeated code might be identified as inlined functions,
dead code may be removed entirely, boolean expressions may be simplified
to reduce the number of logical operationsi, etc. Common subexpressions
may be assigned to temporary variables by either the compiler or the
programmer. Instructions may be reordered for scheduling reasons.
As a result, determining what were the original statements becomes
difficult or even impossible.
Yes, stylized code, when available, as does debugging data, when available,
does reduce the decompilation effort.
I suggest consideration of how the Halting Problem applies to this
situation would be a worthwhile effort.
|Peter Flass <FL...@LBDC.SENATE.STATE.NY.US>
|Systems Programmer -- Team OS/2
|- speaking only for myself -
|NYS Legislative Bill Drafting Commission
|1450 Western Avenue, 3rd floor
|Albany, NY 12203
|Voice:(518)458-5114 FAX:(518)458-5108
Randolph J. Herber, her...@dcdrjh.fnal.gov, +1 630 840 2966,
CD/OSS/CDF CDF-PK-149O Mail Stop 234
Fermilab, Kirk & Pine Rds., P.O. Box 500, Batavia, IL 60190-0500.
(Speaking for myself and not for US, US DOE, FNAL nor URA.)
(Product, trade, or service marks herein belong to their respective owners.)
N 41 50 26.3 W 88 14 54.4 and altitude 700' approximately, WGS84 datum.
Interesting point. I was pondering that question myself, and I'm not
really sure if that is true in the general case. I think that decomposing
C code with a C decompiler on a CISC machine has a different feasability
than the same scenario on a RISC machine. The difference being that
instructions for multiple lines of src code will routinely interleave (as
is also the case with a good optimizer on any machine).
I definitely agree that decomposing to PL/I is much more difficult if for
no other reason than that the size of the PL/I language is just plain
biggerer than C.
-----------Time flies like the wind. Fruit flies like a banana.----------------
--------Stranger things have happened but none stranger than this.-------------
Steven W. Orr ste...@uniprise.com Does your driver's license say Organ Donor?
---------------"Listen to me! We are all individuals."-------------------------
From owner...@PACEVM.DAC.PACE.EDU Tue Jan 21 00:46 EST 1997
I never heard of a visual PL/1, who makes it?
Marc Nissenbaum
ma...@liant.com
"Visual PL/I" is the common name for IBM's PL/I Toolkit.
The Toolkit is an aid for the development of PL/I programs, and comes
with the great editor, LPEX (live parsing editor). [If you want an
excuse to get the toolkit, LPEX is it!].
Apart from LPEX, the Toolkit is intended for the development of
large projects and team projects.
Since Mr. Flass was kind enough to define his own acronym (VDL), what does
"BNF" mean?
-Don Farrar
Walnut Creek, CA
I don't happen to have one, but I'm curious what you want to do with it.
One of the old discussions that comes up every so often is whether you can
take a BNF and write a parser in yacc. It turns out that the PL/I language
does not conform to LALR(1). I've heard a rumor that it may be expressable
as LALR(2). Has anyone got anything more definitive on this?
-----------Time flies like the wind. Fruit flies like a banana.----------------
--------Stranger things have happened but none stranger than this.-------------
Steven W. Orr ste...@uniprise.com Does your driver's license say Organ Donor?
---------------"Listen to me! We are all individuals."-------------------------
On Mon, 20 Jan 1997, John Ashley wrote:
> Can anyone out there point me to a BNF grammar for PL1?
>
> Thanks
>
>
> John Ashley
> Operations Manager
> Software Migrations Limited
> Mountjoy Research Centre
> Stockton Road
> Durham
> United Kingdom
> DH1 3SW
>
> Tel +44 (0) 191 386 0420
> Fax +44 (0) 191 383 1243
>
> Email J.D.A...@durham.ac.uk
> Visit http://www.u-net.com/~sml/index.htm
>
On Tue, 21 Jan 1997, Dave Jones wrote:
> Date: Mon, 20 Jan 1997 12:53:03 +0000
> Reply-To: "PL1 (language) discussions" <PL...@PACEVM.DAC.PACE.EDU>
> Sender: "PL1 (language) discussions" <PL...@PACEVM.DAC.PACE.EDU>
> From: John Ashley <J.D.A...@DURHAM.AC.UK>
> Organization: Software Migrations Ltd
> Subject: BNF for PL1
> To: Multiple recipients of list PL1-L <PL...@PACEVM.DAC.PACE.EDU>
> Status: RO
> X-Status:
>
> Can anyone out there point me to a BNF grammar for PL1?
>
> Thanks
>
>
> John Ashley
> Operations Manager
> Software Migrations Limited
> Mountjoy Research Centre
> Stockton Road
> Durham
> United Kingdom
> DH1 3SW
>
> Tel +44 (0) 191 386 0420
> Fax +44 (0) 191 383 1243
>
> Email J.D.A...@durham.ac.uk
> Visit http://www.u-net.com/~sml/index.htm
I don't have a BNF grammar for PL/I, and, as far as I know, one does
not exist. I do have, however, and am willing to share with you and other
readers of this group a parser for PL/I (full IBM-style PL/I) written in PL/I.
Let me know if there is any interest.
Dave Jones
Velocity Software
On 17-Jan-97 Randolph J. Herber wrote:
>Computers are information destroying machines. That is, like everything
>else in this universe, they increase entropy including information entropy.
>At a minimum, I would expect that all comments and nearly, if not all,
>variable names are lost and can not be reconstructed from the executables.
>It is also quite likely that all but the simplest of the language
>constructs will be lost.
Really ? At the moment i am implementing a dongle software protection for
Pl1-programs running under OS/2. Means the above that it is not possible to
identify and trace certain variables and their content in the memory ?
It would be interesting to hear about it, because this helps to decide which
of the different protection mechanisms of the dongle are effective.
How difficult is it for a hacker to "decrease the entropy" of a protected
executable?
Btw: Do have hackers special problems with thermodynamic calculations ? ;-)
Regards
Franz Kores
The following header lines retained to affect attribution:
|Date: Fri, 17 Jan 1997 18:46:14 +0100
|Reply-To: "PL1 (language) discussions" <PL...@PACEVM.DAC.PACE.EDU>
|From: Franz Kores <023654...@T-ONLINE.DE>
|Subject: Re: Pl1 decompiler
|To: Multiple recipients of list PL1-L <PL...@PACEVM.DAC.PACE.EDU>
|On 17-Jan-97 Randolph J. Herber wrote:
|>Computers are information destroying machines. That is, like everything
|>else in this universe, they increase entropy including information entropy.
|>At a minimum, I would expect that all comments and nearly, if not all,
|>variable names are lost and can not be reconstructed from the executables.
|>It is also quite likely that all but the simplest of the language
|>constructs will be lost.
|Really ? At the moment i am implementing a dongle software protection for
|Pl1-programs running under OS/2. Means the above that it is not possible to
|identify and trace certain variables and their content in the memory ?
With modern compilers, the value of a program variable may be resident in
different locations and different hardware at different time during the
execution of a program. A variable with automatic allocation of its
storage may have no location or value at all outside of the portions of the
program where it is `alive' or it may share storage or compuer hardware
with other variables whose `alive' areas do not overlap its. Even when a
variable is `alive' (the variable has a value which is pertinent to the
program's output), the value of the variable may be in any of a number of
registers and its memory location when it is stored in memory at all may
change from time to time. This can make it very difficult for another
program to locate the variable's current value and where the value is
resident. And, if the compiler is changed, the patterns of where and how a
variable's value is retained may change. In effect, without active
assistance of the compiler (e.g., the debugging data), tracking a variable
can be effectively impossible.
|It would be interesting to hear about it, because this helps to decide which
|of the different protection mechanisms of the dongle are effective.
|How difficult is it for a hacker to "decrease the entropy" of a protected
|executable?
How would a reduction in the information entropy of a protected executable
affect your ``dongle?'' Without that data, I can not offer even a wild guess.
But the information theory equivalent of the First Law of thermodynamics
states that the information content of a _closed_ information system is
monotonically non-decreasing. Therefore, at the first order, my answer
to your question above is that it is impossible.
A review (in a humorous form) of the three laws of thermodynamics:
1. You can't win.
2. You can't break even except under very special circumstances.
3. You can't get out of the game.
|Btw: Do have hackers special problems with thermodynamic calculations ? ;-)
Please, note the reference to ``information entropy.'' It is signal or
information theory that you want to review. But, there are interesting and
subtle connections between thermodynamic entropy and information entropy.
One such connection is that a minimum energy to store 1 bit of information
can be calculated and existing computers are many orders of magnitudes from
being that energy efficient. Furthermore, in both thermodynamics and
information theory, it is closed systems that must be considered.
I am not aware that the hacker (either the old or the current definition)
population has any different degree of difficulty than the general
population with thermodynamic calculations.
|Regards
|Franz Kores
Can anyone out there point me to a BNF grammar for PL1?
On Mon, 20 Jan 1997, John Ashley wrote:
> Can anyone out there point me to a BNF grammar for PL1?
>
AFAIK there ain't no such animal. The original definition of PL/I was in
"VDL" (Vienna Definition Language) and I don't think IBM has made it
net-accessible anywhere (though I'd enjoy being corrected on this.)
--------
*** Reply to note of Tue, 21 Jan 1997 09:09:00 +-130
*** by PL...@PACEVM.DAC.PACE.EDU
Visual PL/I is part of the OS/2 PL/I toolkit. It is a visual builder
somewhat like Visual Basic
On Tue, 21 Jan 1997, Randolph J. Herber wrote:
> Either Backus Normal Form or Backus Naur Form. Most people understand
> that to be the input form accepted by yacc or lex. yacc accept a
> LALR(1) grammar; and PL/1 is at least a LALR(2) --- at at least one
> point in the grammar it is necessary to look ahead two token to
> determine what to do with the current token. This all covered in
> computer science compiler writting courses.
>
I don't remember much about grammars, but PL/I requires a look-ahead of
more than two tokens. Consider the following two statements:
DCL(A,B,C)=5; /* works if DCL is declared as a 3-dimensional array */
DCL(A,B,C) FIXED BIN(15); /* Declares 3 variables A, B, and C */
PL/I was not designed for ease of compilation.
Either Backus Normal Form or Backus Naur Form. Most people understand
that to be the input form accepted by yacc or lex. yacc accept a
LALR(1) grammar; and PL/1 is at least a LALR(2) --- at at least one
point in the grammar it is necessary to look ahead two token to
determine what to do with the current token. This all covered in
computer science compiler writting courses.
Randolph J. Herber, her...@dcdrjh.fnal.gov, +1 630 840 2966,
Actually, your "reality check" has insufficient funds. I can tell you
"horror" tales from the "Little DP Shop of horrors" where load modules
suddenly are discovered to be orphaned from source code modules. In one
case, a VSE shop and an MVS shop, a very bits/bytes/nanoseconds guru was able
to disassemble the load module into Assembler (sans comments) to provide some
sort of "maintainable" source. It isn't a fun project by any means, and
usually, if it must be perfect, it is a eyeball-to-hand job.
I suspect that someone can write a fairly intelligent disassembler one day
which provides the rote work that only the cleverest hackers--mainframe or
microsystem--can accomplish. It would be fairly multiple pass--noting
unconditional jumps, conditional jumps, subroutine calls, then following the
relative and absolute jump paths, generating those awful artificial labels,
and finally the data constants and variable storage areas.
One such disassembler is for the Amiga "toy", and should be available on
ftp-os2.cdrom.com. You might want to check it out... :)
> Disassembly may be accomplished on toy machines (PCs), but the original
> comment about "Reality Check" seems valid for mainframes. I would imagine
>that
> the disassembled code, if it could be generated, would be just as abhorrent
>as
> mainframe Assembler disassembled code: variables usually start with
>at-signs
> and are numbered sequentially, etc. There are modifications to that type
>of
> disassembler which allows you to enter "real" names, but it's awkward.
> Besides, when you think about PL/I and it's subroutines, it becomes a
>nightmare
> just thinking about trying to write a PL/I disassembler.
> Besides, since C code is ugly and unreadable in its original state,
>anything
> generated from a C code disassembler would be just as bad as the original.
>And
> no one would be able to distinguish the two. Who knows, maybe disassembled
>C
> code is easier to read than the original?
> And ADA? What's THAT all about? ADA may be one of the few languages
>even
> more disgusting than C or C++ (or mainframe Assembler, for that matter), so
>the
> fact that it bloats up the object code by stuffing comments into it seems
> appropriate for a Department of Defense language. Since one of the ideas
>of
> mainframe compilers was to generate EFFICIENT code, disassembly was never a
> concern (nor should it be).
> I think that the original note about wanting a PL/I disassembler should
>be
> approached differently: here's an opportunity to rewrite the code, making
> yourself big bucks. If the company was silly enough to lose the source
>code,
> they may be just silly enough to pay you to rewrite the program(s).
> -Don Farrar
> Walnut Creek, CA
> P.S.: I wonder if the previous guy's car (a VW microbus?) has a bunch of
>bumper
> stickers all over the thing, even on the orange body paint (probably a lot
>of
> primer, no doubt), with cute little sayings there, too?
> *******************************************************************************
> Not true. Decompilation is a mysterious concept unless you work on real
> computers: i.e., pc's. There, the concept of decompilation has been well
> developed for a long time. It's typically done in cyclic fashion. Each
> subsequent pass through the executable allows the developer to assign more
> offsets to variable names until the program becomes readable. You are
>correct
> that comments are lost forever, but just for grins, I refer you to the
>Diana
> representation of ADA which was developed back in the early '80s. They made
> comments an integral part of the object file representation. In the ADA
>case,
> it was (theoretically) possible to fully construct the src code from
>objects.
> I have never seen a PL/I decompiler, but decompilation is pretty routine
>for C
> code in the DOS environment.
> -----------Time flies like the wind. Fruit flies like a
>banana.----------------
> --------Stranger things have happened but none stranger than
>this.-------------
> Steven W. Orr ste...@uniprise.com Does your driver's license say Organ
>Donor?
> ---------------"Listen to me! We are all
>individuals."-------------------------
> *******************************************************************************
> On Thu, 16 Jan 1997, Randolph J. Herber wrote:
> A reality check is needed here.
> Computers are information destroying machines. That is, like everything
> else in this universe, they increase entropy including information entropy.
> At a minimum, I would expect that all comments and nearly, if not all,
> variable names are lost and can not be reconstructed from the executables.
>It
> is also quite likely that all but the simplest of the language
> constructs will be lost.
> I have seen 1 successful decompilation effort in thirty years. It was
> a major effort. The language was C which is sometimes called a portable
> assembly language. Its constructs are very simple; nontheless, in the
> decompilation, all the comments, variable names except the external
> routine names and all the loop constructs were lost. All the bit field
> operations were replaced by their equivalent integer logical operations.
>The
> project was determined to be a success because the resultant C code >
>compiled
> to the same executable except for time stamps on the same type of hardware
>and
> the same version of the operating system. If it were not an amateur (in
>the
> original sense and not implying a unprofessional class effort) effort, then
>the
> expense could not have justified for the program in question. The effort
>took
> about 2 man-years for a program of about 10 000 lines.
> Randolph J. Herber, her...@dcdrjh.fnal.gov, +1 630 840 2966,
> CD/OSS/CDF CDF-PK-149O Mail Stop 234
> Fermilab, Kirk & Pine Rds., P.O. Box 500, Batavia, IL 60190-0500.
> (Speaking for myself and not for US, US DOE, FNAL nor URA.)
> (Product, trade, or service marks herein belong to their respective
>owners.)
> N 41 50 26.3 W 88 14 54.4 and altitude 700' approximately, WGS84 datum.
-----------------------------------------------------------
ejo...@ibm.net
-----------------------------------------------------------
On Fri, 17 Jan 1997, Randolph J. Herber wrote:
>
> I did not claim nor did I intend to claim that decompilation is mysterious.
> I did claim and I did intend to claim that it is difficult because much of
> the information in the original source is destroyed in the compilation
> process. Unless the executable format identifies what is instructions
> and what is data, reliably making that determination is difficult and can
> be impossible if the program uses function pointers or similar constructs.
Interesting point though -- although decompilation in the general case is
difficult and error-prone, in the specific case of a particular compiler
it may be less so. Code generated by a compiler will fit specific
patterns or templates for loops, procedure entry and exit, etc.
Decompilation then becomes a pattern-recognition problem.
--------
The C language IS ridiculous. It should be called "C-bonics."
from the archives . . . might be worth contacting the company
to see whether they have produced something for PL/I . . .
_______________________________________________________________
In <4sm88j$1k...@mule2.mindspring.com>, jr...@source-recovery.com (J Rahm) writes
:
>We have been approached to consider expanding our capabilities of
>recovering source code from mainframe load modules to include PL/I.
>Presently, we provide a service of recovering Cobol or Assembler
>source modules but have limited information about PL/I.
>
>Are there any reports or statistics available about the overall usage
>of PL/I as compared to Cobol or Assembler?
>Is the ability to recover missing PL/I source of interest in general?
I never heard of a visual PL/1, who makes it?
Marc Nissenbaum
ma...@liant.com
Before sombody suggests "Backus Normal Form," BNF actually stands for
"Backus-Naur Form."
BNF is a notation used for defining the grammar for a language. In the
programming languages application of the term, a grammar is a set of
rules that defines the sequences of characters that are considered to be
acceptable programs in the language being defined. BNF was developed
(by Backus and Naur) for the syntactic definition of the ALGOL
programming language in 1960.
A BNF grammar is a finite set of BNF rules, that look like the
following:
<assignment statement> ::= <variable> = <expression>
<variable> ::= <alphabetic character> <alphanumeric character>*
When on the left-hand side of the "::=", the stuff in angle-brackets
(less-than and greater-than signs) represents a construct being defined
by the stuff on the right-hand side. When on the right-hand side, the
stuff in angle brackets stands for a construct defined in another rule.
BNF grammars are "context-free," which makes for simpler compiler
construction.
>----------
>From: Don Farrar
>Sent: Tuesday, January 21, 1997 9:17 AM
>To: Multiple recipients of list PL1-L
>Subject: Re[2]: BNF for PL1
>
> Since Mr. Flass was kind enough to define his own acronym (VDL),
>what does
>"BNF" mean?
>
>Date: Mon, 20 Jan 1997 12:53:03 +0000
>Reply-To: "PL1 (language) discussions" <PL...@PACEVM.DAC.PACE.EDU>
>Sender: "PL1 (language) discussions" <PL...@PACEVM.DAC.PACE.EDU>
>From: John Ashley <J.D.A...@DURHAM.AC.UK>
>Organization: Software Migrations Ltd
>Subject: BNF for PL1
>To: Multiple recipients of list PL1-L <PL...@PACEVM.DAC.PACE.EDU>
>Status: RO
>X-Status:
>Can anyone out there point me to a BNF grammar for PL1?
>Thanks
>John Ashley
>Operations Manager
>Software Migrations Limited
>Mountjoy Research Centre
>Stockton Road
>Durham
>United Kingdom
>DH1 3SW
>Tel +44 (0) 191 386 0420
>Fax +44 (0) 191 383 1243
>Email J.D.A...@durham.ac.uk
>Visit http://www.u-net.com/~sml/index.htm
I have a grammar for PL/I. I obtained it from LALR Research in 1988.
The grammar was written for a parser generator named LALR which is a
LALR(1) parser generator. The manual for LALR had the printed address
for LALR Research of 1892 Burnt Mill, Tustin CA 92680 and a telephone
number of 714-832-LALR. However the first page is stamped LALR
Research, P.O. Box 50755, Knoxville, TN 37950 with a telephone number
of 615-691-5257. The manual also contains the name of Paul Mann and
the date of November 1987. I beleive Mr. Mann may have been a computer
science major at California State University Chico in Chico,
California. I know that the parser program is copyrighted and assume
the grammar is also copyrighted but there are no copyright statements
in the file and the only markings on the disk (5 1/4" floppy) are
"PL/I GRAMMAR" and "7-18-88 LALR REASEARCH". I would be gald to post
the grammar if someone could get permission from Mr. Mann or LALR
Research or their successor, if any. I have no idea where Mr. Mann is
or if LALR Research still exist.
I also came across a note that there is a PL/I grammar, called
"plm.shar" archived at iecc.com.
Robert D. McGhie
r...@jps.net
Can anybody help me by pointing me at a comparison of Visual PL/I with other Event-oriented programming systems, particularly Visual Basic and Delphi.
Thank you. Robert Barnes
** Reply to note from "PL1 (language) discussions" <PL...@PACEVM.DAC.PACE.EDU> Wed, 22 Jan 1997 07:43:51 -0600
> P.S. I have a colleague who once had in his office a copy of the VDL. I do
> not
> know if he still has it.
I once had a copy, though it has since disappeared.
It was on onion skin paper and it was thicker than the Chicago white
pages. And it didn't include the whole language.
It was impressive but I don't think it led to anything.
Personally, and with very little expertise, I don't think the syntax is
the hard part. It is easy to tell whether
DCL(A,B,C)=3; and
DCL(A,B,C) FLOAT:
is an assignment statement, just notice the =. But to tell whether
either of them really means, if anything, is much messier.
************************************************************************
* George Yanos *
* GYa...@uic.edu *
* 708-848-4221 *
* Fax:630-323-0924 *
************************************************************************
The following header lines retained to affect attribution:
|Date: Tue, 21 Jan 1997 15:02:07 -0500
|Reply-To: "PL1 (language) discussions" <PL...@PACEVM.DAC.PACE.EDU>
|From: Peter Flass <fl...@LBDC.SENATE.STATE.NY.US>
|Subject: Re: Re[2]: BNF for PL1
|To: Multiple recipients of list PL1-L <PL...@PACEVM.DAC.PACE.EDU>
|On Tue, 21 Jan 1997, Randolph J. Herber wrote:
|> Either Backus Normal Form or Backus Naur Form. Most people understand
|> that to be the input form accepted by yacc or lex. yacc accept a
|> LALR(1) grammar; and PL/1 is at least a LALR(2) --- at at least one
|> point in the grammar it is necessary to look ahead two token to
|> determine what to do with the current token. This all covered in
|> computer science compiler writting courses.
|I don't remember much about grammars, but PL/I requires a look-ahead of
|more than two tokens. Consider the following two statements:
| DCL(A,B,C)=5; /* works if DCL is declared as a 3-dimensional array */
| DCL(A,B,C) FIXED BIN(15); /* Declares 3 variables A, B, and C */
|PL/I was not designed for ease of compilation.
|Peter Flass <FL...@LBDC.SENATE.STATE.NY.US>
|Systems Programmer -- Team OS/2
|- speaking only for myself -
|NYS Legislative Bill Drafting Commission
|1450 Western Avenue, 3rd floor
|Albany, NY 12203
|Voice:(518)458-5114 FAX:(518)458-5108
Unless I misunderstand your example, and I readily admit I might be,
then your example requires at most a single symbol.
(a,b,c) = [x,y,z]
(a,b,c) = (x,y,z)
If, at the syntax level of the language, a [] enclosed entity requires
different processing of the = sign than a () enclosed entity, then a
one symbol look-ahead is needed.
(a,b,c) = [ * x ]
(a,b,c) = [ / x ]
If, at the syntax level of the language, the difference between the * and
the / requires different handling of the = sign, then a two symbol
look-ahead is needed. Looking at the [ symbol is not enough.
Perhaps I got the name wrong, or misunderstood what I was reading.
I thought that IBM had a "Visual PL/I", currently available only for =
OS/2. There was some reference, I think, in the "PL/I for Windows" =
announcement, about it "not yet including Visual PL/I"
----------
From: Marc Nissenbaum[SMTP:ma...@LIANT.COM]
Sent: Monday, 20 January 1997 22:01
To: Multiple recipients of list PL1-L
Subject: Re: Language Comparisons - Visual PL/I /VB/Delphi
American National Standard Programming Language PL/I, X3.53-1976. ANSI Inc, New
York, 1976 gives a formal definition of "Standard PL/I". I'm not sure if this
is still available, and I doubt that it's available in machine-readable form.
Rgrds, Robert Barnes
----------
From: Peter Flass[SMTP:fl...@LBDC.SENATE.STATE.NY.US]
Sent: Wednesday, 22 January 1997 03:08
To: Multiple recipients of list PL1-L
Subject: Re: BNF for PL1
On Mon, 20 Jan 1997, John Ashley wrote:
> Can anyone out there point me to a BNF grammar for PL1?
>
AFAIK there ain't no such animal. The original definition of PL/I was in
"VDL" (Vienna Definition Language) and I don't think IBM has made it
net-accessible anywhere (though I'd enjoy being corrected on this.)
--------
It is possible to express a grammar in an intuitive manner that is
equivalent to another form which might be less intuitive. Further, the
less intuitive form may have a lower look ahead factor. I have written
yacc code before which yacc barfed on, only to find out that the grammar
was LALR(2). yacc has no way of detecting that the grammar it is reading
is not LALR(1) and does the best it can.
I remember hearing somewhere that PL/I had been able to be expressed as
LALR(2) even though that was not the most intuitive representation.
Another possible candidate is an LL(k) generator called pccts, available
as freeware. When the generator is run, you specify k=2 on the command
line.
LL is just another word for recursive descent but the functionality is
pretty much the same.
-----------Time flies like the wind. Fruit flies like a banana.----------------
--------Stranger things have happened but none stranger than this.-------------
Steven W. Orr ste...@uniprise.com Does your driver's license say Organ Donor?
---------------"Listen to me! We are all individuals."-------------------------
On Tue, 21 Jan 1997, Peter Flass wrote:
> On Tue, 21 Jan 1997, Randolph J. Herber wrote:
>
> > Either Backus Normal Form or Backus Naur Form. Most people understand
> > that to be the input form accepted by yacc or lex. yacc accept a
> > LALR(1) grammar; and PL/1 is at least a LALR(2) --- at at least one
> > point in the grammar it is necessary to look ahead two token to
> > determine what to do with the current token. This all covered in
> > computer science compiler writting courses.
> >
>
> I don't remember much about grammars, but PL/I requires a look-ahead of
> more than two tokens. Consider the following two statements:
> DCL(A,B,C)=5; /* works if DCL is declared as a 3-dimensional array */
> DCL(A,B,C) FIXED BIN(15); /* Declares 3 variables A, B, and C */
> PL/I was not designed for ease of compilation.
>
From: Peter Flass <fl...@LBDC.SENATE.STATE.NY.US>
I don't remember much about grammars, but PL/I requires a look-ahead of
more than two tokens. Consider the following two statements:
DCL(A,B,C)=5; /* works if DCL is declared as a 3-dimensional array */
DCL(A,B,C) FIXED BIN(15); /* Declares 3 variables A, B, and C */
PL/I was not designed for ease of compilation.
PL/I was desined to be easy to use. That is the important point.
(We've seen what happens with languages that are designed to be
easy to compile!)
Whether PL/I was or not easy to compile is relatively unimportant.
It is the user who is -- or should be -- the prime consideration in
language design.
Peter Flass <FL...@LBDC.SENATE.STATE.NY.US>
OK, here comes a low-level, stupid question:
1. DCL (A,B,C) INIT(D=1);
What is that? Does that mean that if D equals 1, then initialize the
variables A,B, and C to '1'B? And if not, then init them to '0'B? Or is there
more to this type of INIT statement? Or is this an erroneous statement? OK,
that was more than one question ...
-Don Farrar
Walnut Creek, CA
********************************************************************************
>Consider statements like:
IF (X) = Y;
IF (X) = Y THEN DO;
DCL (A,B,C) INIT (D = 1);
DCL (A,B,C), INIT (D) = 1;
DO WHILE ((X) = 0);
DO WHILE (X) = 0 TO 10;
DO_WHILE (X) = 0;
- seb
> OK, here comes a low-level, stupid question:
>1. DCL (A,B,C) INIT(D=1);
> What is that? Does that mean that if D equals 1, then initialize the
>variables A,B, and C to '1'B? And if not, then init them to '0'B? Or is there
>more to this type of INIT statement? Or is this an erroneous statement? OK,
>that was more than one question ...
Admittedly I haven't tried to compile this, but I intended that
statement to mean that the initial value of A, B and C was the
Boolean value 0 or 1, depending on whether D was equal to 1 or not.
So your guess was correct, or at least matched my view.
As far as I know that is legal PL/1, and if it isn't, it still falls
within the realm of comprehensibility and is clearly not an
assignment, whatever it is.
- seb
> > Can anyone out there point me to a BNF grammar for PL1?
> >
> > Thanks
> >
... snip ....
> > Email J.D.A...@durham.ac.uk
> > Visit http://www.u-net.com/~sml/index.htm
>
> I don't have a BNF grammar for PL/I, and, as far as I know, one does
> not exist. I do have, however, and am willing to share with you and other
> readers of this group a parser for PL/I (full IBM-style PL/I) written in PL/I.
> Let me know if there is any interest.
>
> Dave Jones
> Velocity Software
Aha ! Now maybe I can see just how much it might take to do a full
HMP/2 !
(HMP => High-Level MultiPurpose Language => High Level Macro Processor
=> one
heck of a macro front end for PL/I and other languages.)
If it's available in a few weeks (after I shake some wierd bugs out of
the
hardware in my research machine), I'll try to pick this up.
Regards,
John H. Lindsay,
Mathematics and Computer Science,
Royal Military College of Canada,
Compiling on OS/2 gives an error level diagnostic saying that an
expression in an INIT requires parens. Putting them in confirmed your
first hypothesis.
NO, you were not wrong about that. There is a Visual toolkit for PL/I that you use
to develop PM apps on the desktop. It costs about $130 at Indelible Blue.
If you're a PL/I'er, like me, get it! The toolkit is a "national necessity". It reduces
your developing time by a wide margin.
G. Mella
You need an extra set of () around D=1. it will work as you first thought it would.
TEST:PROC OPTIONS(MAIN);
dcl D fixed init(1);
DCL (A,B,C) bit(1) INIT((D=1));
if B then put skip list("It worked!");
END TEST;
Compiled and executed under OS/2 Warp 4.0
G. Mella
Not correct; this is a legal assignment statement.
> > DO WHILE ((X) = 0);
> ^ no operator, this is a DO
> > DO WHILE (X) = 0 TO 10;
> ^ likewise
> > DO_WHILE (X) = 0;
> > ^one word, so this is an assignment.
> > Of the seven statements above, how many are assignments are
> > how many are not? How many contain any kind of assignment
> > at all as opposed to a test for equality?
> > Can you pick them out by simply scanning for the "=" sign?
> The = isn't important here, but the presence of absence of some
> token, and the token always shows up early. It is hard to put PL/I
^^^^^
> into BNF, but it is still just an ordinary language for parsing. Big,
> but ordinary.
>
The "presence or absence of some token" does not need to be "early". In
the case of the DCL statement, for example, the list of variables can be
arbitrarily long and the parser cannot determine, until it gets to the
token following the right parenthesis (or even one token beyond that),
whether the statement is an assignment or a declaration.
Norm
It's the same on an IBM MVS/TSO ISPF env.
Following compile messages:
END OF STATEMENT ASSUMED AFTER '(A,B,C) INIT(D=1'. T
INVALID ATTRIBUTE SPECIFICATION AFTER '(A,B,C) INIT(D'.
RIGHT PARENTHESIS ASSUMED AFTER '(A,B,C) INIT(D'.
Yep. PL/I does not fit nicely into LALR(1). However, you can make it
work if you have an LALR(1) parser generator that allows multi-token
lookahead.
--
=======================================================================
= Charles Stump, Director of Business Development, cst...@levtech.com =
=======================================================================
= Leverage Technologists, Inc. = Reverse Engineering, =
= 6701 Democracy Blvd. = Reengineering, =
= Bethesda, MD 20817 = Maintenance, and =
= Suite 324 = Quality Assurance =
= (301)309-8783 = tools and services. =
= http://www.levtech.com/ = =
=======================================================================
>Before sombody suggests "Backus Normal Form," BNF actually stands for
>"Backus-Naur Form."
>
>BNF is a notation used for defining the grammar for a language. In the
>programming languages application of the term, a grammar is a set of
>rules that defines the sequences of characters that are considered to be
>acceptable programs in the language being defined. BNF was developed
>(by Backus and Naur) for the syntactic definition of the ALGOL
>programming language in 1960.
Isn't Backus the jeans-wearing IBM guru? Father of Fortran?
In <Pine.BSI.3.95.970121...@Starbase.NeoSoft.COM>, Dave Jones <djo...@starbase.neosoft.com> writes:
In <Pine.BSI.3.95.970121...@Starbase.NeoSoft.COM>, Dave Jones <djo...@starbase.neosoft.com> writes:
>I don't happen to have one, but I'm curious what you want to do with it.
>One of the old discussions that comes up every so often is whether you can
>take a BNF and write a parser in yacc. It turns out that the PL/I language
>does not conform to LALR(1). I've heard a rumor that it may be expressable
>as LALR(2). Has anyone got anything more definitive on this?
>
>-----------Time flies like the wind. Fruit flies like a banana.----------------
>--------Stranger things have happened but none stranger than this.-------------
>Steven W. Orr ste...@uniprise.com Does your driver's license say Organ Donor?
>---------------"Listen to me! We are all individuals."-------------------------
>
>On Mon, 20 Jan 1997, John Ashley wrote:
>
>> Can anyone out there point me to a BNF grammar for PL1?
>>
>> Thanks
>>
>>
>> John Ashley
>> Operations Manager
>> Software Migrations Limited
>> Mountjoy Research Centre
>> Stockton Road
>> Durham
>> United Kingdom
>> DH1 3SW
>>
>> Tel +44 (0) 191 386 0420
>> Fax +44 (0) 191 383 1243
>>
>One of the advantages of PL/I is that you don't have to worry about
>inadvertently using one of the many keywords and causing an error.
People
>don't (at least I hope they don't) use such obvious words as DCL
>for the name of an array or whatever. (While I haven't done a recent
>count of the keywords, at last count there were 97 new built-in function
>names in PL/I for OS/2 . . .)
The fact that keywords are not reserved makes it easier for the implementor
(or standards committee) to introduce new ones; in C/C++ this would cause
an outcry which would effectively eliminate the expansion of the language
(except by using an existing keyword in another context).
The BUILTIN function example is less pertinent as a declaration can easily
set the context of the contested symbol. Still, a source code change might
be required if the program author depended upon the default context (a
programmer's design error, IMO).
Does StarTool include parellel edit, and if so what will be the increased
licencing cost over PDSTOOLS?
>And while we are at it, will someone explain "dongle"?
A "dongle" is a hardware device containing a unique key to prevent
unlicenced users from using a piece of software.
Dongles are one of the most universally hated indicators of a lack of trust
from a software publisher, more so than copy protected media which fail on
the next generation floppy drive.
ejo...@ibm.net wrote in article <5ced6p$2gfq$4...@news-s01.ny.us.ibm.net>...
> Yes, but if you happen to have a BNF analyzer (say XPL) then you could
generate
> parsers until you had no disk space. Isn't XPL documented in some old
textbook on
> compiler generators and compiler-compilers?
Yes,
The title is: A Compiler Generator, McKeeman, Horning, Wortman,
Prentice-Hall, 1970
Kurt
"Old PL/1 programmer (1967-1976) never die, they switch to C++"
: Can anyone out there point me to a BNF grammar for PL1?
I wrote a BNF grammar for PL/I, at least some kind of.
The grammar is neither LALR(1), LALR(2), nor LALR(k) for any k.
Some cases such as DCL (A, B, C) = 1; require unlimited lookahead.
Therefore the grammar is augmented by predicates and hints for
backtracking and I am using the parser generator Lark of the
Cocktail Toolbox which understands and supports these extensions.
Best regards
Dr. Josef Grosch
CoCoLab - Datenverarbeitung
Hagsfelder Allee 16
D-76131 Karlsruhe
Germany
Tel.: +49-721-697061
Fax : +49-721-661966
Mail: gro...@cocolab.sub.com
>However, why not just call things like "DCL (A,B,C) = 3;" an error?
Two reasons. First, it would mean that you would have to know the entire language
instead of just the part that you want to use. Second, it would mean that every time
they added new key words they would break existing programs.
Shmuel (Seymour J.) Metz
Systems Programmer & JOAT
Atid/2
Any unsolicited commercial junk E-mail will will be subject to
legal action.
I added an * to my E-mail address to foil automated spammers;
remove it to contact me.
I do not beleive it is possible to fully document PL/I with a BNF
definition.
Why? Because the original language definition was done in a notation
style that was a very large expansion of BNF.
As it tooks a "couple" of weeks to learn how to read the notation, I am
sure that it would have been done in BNF, had that been possible.
Many years ago, I had access to the original Vienna Documents, and I was
told at that time that the bookcase shelf would have had to been a
bookcase or two, had standard BNF been "used".
...and the resulting document would be totally unreadable.
(The Vienna Documents were bad enough!)
So many people misunderstood the original documentation that IBM pulled
it and the so called "Language Reference Specifications" from
publication around 1968. (The Vienna documents were only available to
a select few - and a non-disclosure was required. I remember the wording
on that particular ND to be very tight - which probably is one of the
main reasons why the language was not universally implemented across the
manufacturers platforms of that era.)
Yes, PL/I's major problem, was (and still is) that "It provided enough
rope to hang the programmer" and many programmers invoked that
option....
I, for one, still prefer the language, and while I no longer use the
language actively, most of my pseudo code would probably compile as a
working (but inefficient) program!
Cheers.
/s/ Bill Turner, wb4alm