Re: COBOL's Influence on C


Robert <no@xxxxxx> wrote in message
news:dsmhj317b7236kep9l7j2i53jp39dcvlo6@xxxxxxxxxx
On Mon, 12 Nov 2007 10:19:38 -0500, "Rick Smith" <ricksmith@xxxxxxx>
wrote:

Modern BASICs also use conditions in the SELECT CASE
statement and may have been influenced by COBOL. <g>

Speaking of modern BASICs ...

GOSUB, which is the same as Cobol's out of line PERFORM, has been
depreciated by many/most
compilers and dropped from VB.NET. It was replaced by SUB, which is a
local function
call. In my opinion, Cobol should have done the same.

In my opinion and usage, the word SUB, short for SUBroutine, refers to a
stand-alone piece of code not included with the source program under
consideration. (It can certainly be in the same compilation unit, of
course). A function in this context is some common routine which isn't
compiled (I say this to keep OO vocabulary out of the discussion), usually
supplied by the compiler writers: e.g., calls on the OS. There should be a
completely different verb to execute sections of code within the source
program as opposed to that used to execute wholly external sections.
COBOL's PERFORM does the first perfectly well - unambiguous,
understandable - and CALL (or INVOKE, etc.) does the second: and neither can
be mistaken for the other. Why change?

In PROGRESS, a language I have little love for but have had to use quite a
bit, the in-line perform is WHILE, and the out-of-line perform is RUN: but
RUN is also used as the CALL. If the label isn't defined within the current
source, it's assumed to be an external routine: no precautionary diagnostic.
So it's very common to have a clean compile which then blows up with
unresolved linkages when attempting to execute. Not the same situation as
what Robert's suggesting but a cautionary tale.

PL


.

Relevant Pages

  • Re: An Observation
    ... compilation and store their strings to use when executing. ... Simplified control structures similarly. ... Avoiding STATE is another simplicity, but one that only works when you ... DOES> words return the address and then execute the xt. ...
    (comp.lang.forth)
  • Re: Is interpret/compile the wrong distinction?
    ... execute it and discard it, or you leave it added to the dictionary. ... defining words with special compilation semantics. ... and dual xt dictionaries to try and get the ... complexity when you make them, and it's as bad as the complexity of an ...
    (comp.lang.forth)
  • Re: The IMMEDIATE mess
    ... for words with default compilation semantics: ... If you aren't limited to EXECUTE ... You'd have a word to give an existing word new compilation behavior. ...
    (comp.lang.forth)
  • Re: Dual XTs (compilation tokens) and DOES>
    ... Sure it is a problem with ANS. ... Either the EXECUTE is slow (compared to ... compilation tokens instead of addresses of code. ... IMMEDIATE, it does this immediate, otherwise it does it not immediate ...
    (comp.lang.forth)
  • Re: The IMMEDIATE mess
    ... Usually what we need is not IMMEDIATE words or state-smart words. ... The issue doesn't come up after you execute the words. ... -3 normal compilation behavior, do not interpret. ... The part before compilation> is interpret time (and is the xt returned ...
    (comp.lang.forth)