sharp@usceast.UUCP (Harry Sharp) (10/17/89)
Greetings,
I am attempting to locate a copy of a PL/I or PL/C grammar to use
in creating a PL/I to C translator. This is a part of my Master's thesis.
Does such a beast exist? I have been told that PL/I cannot be parsed LALR.
Is this true? (I hope not.)
If anyone has information leading to a grammar (preferrably in BNF),
would they either post or e-mail me their information? I would most
appreciative.
Thanks in advance.
Harrison
sharp@cs.scarolina.edu
--
[=============================================================================]
USMail : Dept of Computer Science, USC, Columbia, SC 29208
E-mail : gatech!hubcap!usceast!sharp sharp@cs.scarolina.edu
GO COCKS! You can't lick our cocks! Univ. of South Carolinajohnl@esegue.segue.boston.ma.us (John R. Levine) (10/18/89)
In article <2956@usceast.UUCP> sharp@usceast.UUCP (Harry Sharp) writes: > I am attempting to locate a copy of a PL/I or PL/C grammar to use >in creating a PL/I to C translator. This is a part of my Master's thesis. >Does such a beast exist? I have been told that PL/I cannot be parsed LALR. >Is this true? (I hope not.) PL/I has no reserved words, which makes it pretty exciting to parse using context-free methods. You can, for example, call a variable READ or DECLARE. Once you deal with that problem (by prescanning statements) the grammar is supposed to be context free and yacc could probably handle it. The ANSI PL/I standard has a BNF concrete syntax that is about 15 pages of single-spaced text. That's probably as good a place to start as any. The semantics are messy, too. Consider: A = B = C; which compares B and C and sets A to '1'B if they are equal. This is no problem for yacc to handle, but it's a pain for humans. What a language. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl Massachusetts has over 100,000 unlicensed drivers. -The Globe
perry@apollo.HP.COM (Jim Perry) (10/19/89)
In article <1989Oct18.012237.548@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes: >The semantics are messy, too. Consider: > > A = B = C; > >which compares B and C and sets A to '1'B if they are equal. This is no >problem for yacc to handle, but it's a pain for humans. What a language. As opposed, say, to the clean semantics of something like (from C): if (a = b) c(); which assigns b to a and then executes the function c if b was not zero, or if (a == b) c; which does nothing (assuming a & b are variables, c a function). One might argue that "a := b = c;" better expresses the intent of the original statement, unless the intent was actually "a, b = c;", which is of course what a PL/I programmer would have written in that case. (A PL/I programmer would have written the former case as "a = (b = c);"). Don't get me wrong, I don't defend PL/I as the world's greatest language, but in a world where C is the lingua franca, I'll stick up for it. Minor syntax mistakes a native speaker of C might make in PL/I are much more likely to be detected as errors than the reverse. Jim Perry perry@apollo.com HP/Apollo, Chelmsford MA This particularly rapid unintelligible patter isn't generally heard and if it is it doesn't matter.
gateley@m2.csc.ti.com (John Gateley) (10/20/89)
In article <1989Oct18.012237.548@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes: >The semantics [of PL/I] are messy, too. Consider: > A = B = C; >which compares B and C and sets A to '1'B if they are equal. Minor nit: this is not messy semantics, this is still messy syntax. Consider the Lisp version of the above statement (which is pretty close to an abstract syntax tree): (setq a (= b c)) The semantics are perfectly clear, it is the syntactic overloading of '=' which makes the above statement messy. (I know my Lisp version doesn't correspond exactly, but the ``correct version'' is more complex and doesn't add anything to the discussion). John gateley@m2.csc.ti.com
bard@brigid.cs.cornell.edu (Bard Bloom) (10/20/89)
IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF only in PL/I... (I hope)
rhg@cpsolv.UUCP (Richard H. Gumpertz) (10/21/89)
In article <2956@usceast.UUCP> sharp@usceast.UUCP (Harry Sharp) writes: >... I have been told that PL/I cannot be parsed LALR. >Is this true? (I hope not.) That is indeed true. Many constructs cannot be recognized until after you read past arbitrarily nested parentheses, thus killing any limited-lookahead parser. Another amusing problem is that there are NO reserved keywords. One can even declare variables with the same names as the builtin keywords! Hence, with the appropriate declarations preceding, the PL/I loop DO DO = TO TO BY BY WHILE (BEGIN = END) WHILE (BEGIN = END); BEGIN; ... END; END; is legal. For those not familiar with PL/I, it is roughly equivalent to the C loop for (increment = WHILE(BEGIN == END), limit = BY, *(index = &DO) = TO; (increment >= 0 ? *index <= limit : *index >= limit) & (BEGIN == END); *index += increment) { ... } where index, increment, and limit are automatically declared with appropriate type. The order of evaluation of the four assignments on the first line is not defined by the PL/I language. No, the & in the second line shouldn't be an &&. -- ========================================================================== | Richard H. Gumpertz rhg@cpsolv.UUCP -or- ...!uunet!amgraf!cpsolv!rhg | | Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749 | ==========================================================================
bothner@decwrl.dec.com (Per Bothner) (10/23/89)
In article <422@cpsolv.UUCP> rhg@cpsolv.uucp (Richard H. Gumpertz) writes: > (increment >= 0 ? *index <= limit : *index >= limit) & (BEGIN == END); > No, the & in the second line shouldn't be an &&. Could you please explain how && and & could be different in this case? -- --Per Bothner Western Software Lab, Digital Equipment, 181 Lytton Ave, Palo Alto CA 94301 bothner@wsl.dec.com ...!decwrl!bothner
diamond@csl.sony.co.jp (Norman Diamond) (10/23/89)
In article <33398@cornell.UUCP> bard@cs.cornell.edu (Bard Bloom) writes: >IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF > >only in PL/I... (I hope) Only by an idiot in PL/I. The value of a language comes from ALLOWING a good programmer to write a good program. Attempts to disable bad programming usually cause side effects which are worse. How recently was the dispute in this newsgroup about Bondage & Discipline languages? An idiot could write a C program with a variable named just _ (an underscore). The Extended Pascal committee didn't like this, so they made a more restrictive and more complicated rule for where underscores are allowed. So if I'm debugging and want to create a variable for a short time, intending to delete it later, I cannot call it "debug__a" (two consecutive underscores are not allowed). I cannot imagine any programming style where I would want two consecutive underscores in a finished program -- and neither could the rest of the committee so they disallowed it altogether. If you measure each language by the worst program that could possibly be written by an idiot, then you will have to hate every language even more than Dijkstra does. You might as well get out of this profession and leave it for the rest of us. The English language is terrible too. It permitted my boss to lie to me. All together now, let's criticize English and find a language where lies are impossible. -- Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work) Should the preceding opinions be caught or | James Bond asked his killed, the sender will disavow all knowledge | ATT rep for a source of their activities or whereabouts. | licence to "kill".
rhg@cpsolv.UUCP (Richard H. Gumpertz) (10/23/89)
In article <1962@bacchus.dec.com> bothner@decwrl.dec.com (Per Bothner) writes: >In article <422@cpsolv.UUCP> rhg@cpsolv.uucp (Richard H. Gumpertz) writes: >> (increment >= 0 ? *index <= limit : *index >= limit) & (BEGIN == END); >> No, the & in the second line shouldn't be an &&. > >Could you please explain how && and & could be different in this case? I was trying to be as precise as possible. They differ if the evaluation of BEGIN or END generates side-effects: the WHILE(...) clause in PL/I is evaluated even if the loop is ready to terminate. A minor point; I probably shouldn't have even pointed it out. -- ========================================================================== | Richard H. Gumpertz rhg@cpsolv.UUCP -or- ...!uunet!amgraf!cpsolv!rhg | | Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749 | ==========================================================================
tneff@bfmny0.UU.NET (Tom Neff) (10/23/89)
In article <10986@riks.csl.sony.co.jp> diamond@ws.sony.junet (Norman Diamond) writes: >In article <33398@cornell.UUCP> bard@cs.cornell.edu (Bard Bloom) writes: > >>IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF >> >>only in PL/I... (I hope) > >Only by an idiot in PL/I. ... Where are all these sentiments when the Obfuscated C Contest rolls around, I wonder? Does C have a monopoly on FUN in programming?? :-) -- "We must never forget that if the war in Vietnam \ $ Tom Neff is lost... the right of free speech will be X tneff@bfmny0.UU.NET extinguished throughout the world." -- RN 10/27/65 $ \ uunet!bfmny0!tneff