COBOL does rely on the period. -Bob -- bbrown at harpercollege.edu #### #### Bob Brown - KB9LFR Harper Community College ## ## ## Systems Administrator Palatine IL USA #### #### Saved by grace

On 6/22/2006 at 8:03 AM Rob O'Donnell wrote: AFAIK, COBOL still requires a period after paragraph names. Prior to ANSI85 COBOL, a period was necessary inside of a conditional as a terminator. ANSI85 introduced the END-IF word, which could be used in place of the required period (just a case of using a word instead of punctuation). The need for a period to terminate a conditional (e.g. IF) was the result of the following general syntax: IF <condition> <statement-list>. In other words, IF BIG-NUMBER GREATER 100 DISPLAY "HOWDY" ADD 1 TO HIT-COUNT. In ANSI85 COBOL, the period could be replaced with END-IF. This was a nasty bit of inherited syntactical grief from earlier versions of COBOL. In retrospect, requiring some sort of conjunction before each statement in an IF statement list would have made more sense. e.g.: IF BIG-NUMBER GREATER 100 THEN DISPLAY "HOWDY" THEN ADD 1 TO HIT-COUNT ... But backward compatibility was required so the old syntax stayed. In general, you used periods only where needed, as they could be troublemakers otherwise. Consider the above statement with a period after "HOWDY"--the whole sense of the fragment is changed. IIRC, some compilers required a period at the end of the last statement in a paragraph also. Cheers, Chuck

On 6/21/06, Don Y <dgy at dakotacom.net> wrote: And RPN languages like Forth can even do away with parentheses. However I don't know that you could call Forth "punctuation free" or even Regular (in the sense of not needing a parser). In general Forth is processed one word at a time with an ad hoc lexer + smarts. Some words read ahead in the input stream, and state during parsing is important. -- John.

It was thus said that the Great John R. once stated: Well, in Forth, functions are called "words" and + is a word. So is (. As is @. And !. As well as 0 [1], 1 [1] and 2 [1]. There are only a few words (in ANS Forth) that require looking ahead and they're well known. Most of the words in Forth pull parameters off the stack. -spc (And one can always rename @ as fetch) [1] To conserve space. Otherwise, numbers are stored as two cells: the address for "push the following value onto the stack" function, and then the actual value. 0, 1 and 2 are used enough to warrent their own words.

John R. wrote: I tried to qualify my use of the term "punctuation" (cf. ispunct()). An easy way of defining it is to think of how you could READ a line of code to another person over the telephone, unambiguously WITHOUT THAT PERSON BEING FAMILIAR WITH THE LANGUAGE (i.e. if he was familiar with the syntax, he would know where parens were implied, etc.). So: A = B + 1 technically has two bits of punctuation but they are semi-intuitive; one would assume "equals" to mean '=', etc. OTOH: A ::= B + 1 Would be read as "A colon colon equals B plus one". So, the colons here act as nonintuitive punctuation while the '+' does not. Likewise, ending statements with semicolons, inserting commas, etc. all qualify as punctuation. And, parens/braces/brackets are particularly nasty: "foo open paren bar close paren"

woodelf wrote: This is how I learned "programming" back in the dark ages (though it was expressed as A <- B + 1 and read as "A gets B + 1) This is perl-esque. Fine for a procedure. But, what if foobar is a *function*! It's *really* hard to mess with this syntactic sugar -- we've all become so used to seeing and using it that it's ingrained in our expectations. :-(

On 6/22/2006 at 12:25 AM woodelf wrote: Algol-60 definitely embodied a stack notion--it was one of the few programming lanugages that included recursion as a feature. FORTRAN and COBOL defintely did not--and compilers typically generated code that saved registers, arguments and return addresses in static memory areas. Cheers, Chuck

It was thus said that the Great John R. once stated: Well, having written my own Forth-like language the only hack I found I needed was a way of recognizing a quote terminated string and dumping it (the string) on the stack. So I didn't have to read ahead into the input stream ... well ... not in the way that : does in Forth. I did something like: "foo" define ( the code for foo here ... ) ; (only, it looked more like: "foo" :' ( the code for foo here ... ) ; ) There's no need to read ahead for loops either and I supported while, until and just about any other type of loop you care to do. Here's the code I had for supporting higher level loops (and yes, I did support the Forth word : in my language anyway): // '(barf)' '(brat)' '(bra)' 'here' and '(resolve)' are the low level routines to // implement branches of various types. : c(barf) '(barf)' find drop compile ; // compile a branch if false : c(brat) '(brat)' find drop compile ; // compile a branch if true : c(bra) '(bra)' find drop compile ; // compile a branch : (mark) here -1 compile ; // leave fixup addr on stack : resolve here swap (resolve) ; // resolve foreare/back branch ( the always popular if else then clause ... ) : if c(barf) (mark) ;imm : ifnot c(brat) (mark) ;imm : else c(bra) (mark) swap resolve ;imm : then resolve ;imm // because it's been like this : endif resolve ;imm // because some might like this better ( some otherwise neato control flow words ... ) : begin here ;imm : until c(barf) here - compile ;imm : notuntil c(brat) here - compile ;imm : while c(barf) (mark) ;imm : whilenot c(brat) (mark) ;imm : repeat c(bra) swap here - compile resolve ;imm -spc (Even used this language for a class in college for a project)

---snip--- One could add one more level to the typical forth interpreter. Most Forth interpreters first check to see it the word is in the dictionary. If it is not there, it would see if it could be a number. If not that, it must be an error. One could add one additional level to cause a word to be placed on a sting stack or string buffer. Something like: Hello$ World$ 2 $type would replay with: Hello World Defining a word would be: Hi$ : Hello$ World$ $type ; It has no look ahead. It does reduce the number of possible names one could use for word, since none can end in $. It does simplify string handling for the interpreter but makes it harder for the programmer. Dwight

On Wed, 21 Jun 2006, Don Y wrote: Algol's syntax constists of symbols like '<-' ';' and so on. If you read e.g. the book from the Alcor group you will see that they tell you, in case that there are no '<-' etc. you may use more primitive symbols to represent them, e.g. ':=' = '<-' '.,' = ';' '..' = ':' '.(' = '[' '.)' = ']' and so on. Now think if you want to write '<-' and don't even have a ':' ... Right, you have to write '..=' In Pascal, e.g., you can write '(*' and '*)' instead of '{' and '}' if you don't have curly brackets. Christian

Christian Corti wrote: Yes, sorry, I misremembered: ::= is the syntax for BNF's introduced in the '68 report. And in C you can use the pre-preprocessor trigraphs, etc.

Sridhar Ayengar wrote: REXX has more than it's share of punctuation. '~' essentially replaces C's '!' it shares the '==' operator, adds exponentiation via '**' replaces C's '%' with '//' adds '||' for concatenation '/*' comments semicolons to separate statements on the same line (though C requires semicolons for "all" statements) '%' for integer division periods to separate "elements"/records/members of compound variables parens for function invocations colons to delimit label clauses Plus, I recall lots of quoting when writing REXX scripts. OTOH, I don't recall *braces* used anywhere :>