Cobol - GoTo in Java

Author

GoTo in Java

Howard Brazee

2006-01-17, 6:55 pm

It is interesting that Java, where the word GOTO is reserved but not
used, it has a label and a GoTo equivalent to tell us how to exit a
multi-layer iteration (perform loop).

I wish we had an equivalent in CoBOL.

Peter Lacey

2006-01-17, 6:55 pm

Howard Brazee wrote:
>
> It is interesting that Java, where the word GOTO is reserved but not
> used, it has a label and a GoTo equivalent to tell us how to exit a
> multi-layer iteration (perform loop).
>
> I wish we had an equivalent in CoBOL.

We do, dammit (if I undersrand what you're saying). GOTO, GOTO
equivalent - what's the point? GOTO works, does just what an equivalent
would do. Stop being stubborn.

(Cancel this if you're trolling).

William M. Klein

2006-01-17, 6:55 pm

In the '02 Standard and some current implementations (but alas NOT IBM's).

Exit PERFORM (cycle)

--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message
news:dnnqs1tjutcc64coojpi0k06g2jrlopf38@
4ax.com...
> It is interesting that Java, where the word GOTO is reserved but not
> used, it has a label and a GoTo equivalent to tell us how to exit a
> multi-layer iteration (perform loop).
>
> I wish we had an equivalent in CoBOL.
>
>

Chuck Stevens

2006-01-18, 9:55 pm

I think what he was looking for was exit from PERFORMs of any level,
analogous to Burroughs B1000 SDL/UPL (and almost certainly
Dijkstra-inspired)
...
DO <label-1> FOREVER;
DO <label-2> FOREVER;
DO <label-3 FOREVER;
...
IF <condition-1> THEN UNDO; % transfers control to just after
END <label-3>
IF <condition-2> THEN UNDO <label-2>; % control to after END
<label-2>
IF <condition-3> THEN UNDO *; % control to outermost DO within
procedure
END <label-3>;
END <label-2>;
END <label-1>;

You can certainly EXIT the "innermost" PERFORM in COBOL, but there's no
provision to EXIT, say, the fifth nested PERFORM level above you in the
hierarchy.

-Chuck Stevens

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:yBfzf.123644$Es3.36473@fe03.news.easynews.com...
> In the '02 Standard and some current implementations (but alas NOT IBM's).
>
> Exit PERFORM (cycle)
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:dnnqs1tjutcc64coojpi0k06g2jrlopf38@
4ax.com...
>
>

Howard Brazee

2006-01-18, 9:55 pm

On Tue, 17 Jan 2006 17:53:34 -0600, Peter Lacey <lacey@mts.net> wrote:

>
>We do, dammit (if I undersrand what you're saying). GOTO, GOTO
>equivalent - what's the point? GOTO works, does just what an equivalent
>would do. Stop being stubborn.
>
>(Cancel this if you're trolling).

There are two ways to have internal loops:

PERFORM VARYING.....
PERFORM VARYING....
IF I-AM-FINISHED
EXIT PERFORM
END-IF
END-PERFORM
END-PERFORM

I am not sure, but I think the EXIT PERFORM will have the ability to
pick which level is being exited from. At any rate, I can't do this
now.

Let's say I want to go the GOTO route as you say. I can't use the
existing code, but would need to rewrite the logic.
IF FOUND-SUBCODE
PERFORM SUBCODE-ROUTINE
PERFORM WRITE-RESULTS
END-IF
...
SUBCODE-ROUTINE.
...
IF FINISHED-SUBCODE
PERFORM CHECK-INVENTORY
PERFORM ADD-TO-BIN
END-IF.
....
CHECK-INVENTORY.
...
IF NEED-TO-EXIT
GO TO ??????
END-IF.
....

Let's say I want to go to PERFORM WRITE-RESULTS at this case. I
need to set up switches or rewrite the logic (which is frowned at with
working code).

John Culleton

2006-01-18, 9:55 pm

Chuck Stevens wrote:
[color=darkred]
> I think what he was looking for was exit from PERFORMs of any level,
> analogous to Burroughs B1000 SDL/UPL (and almost certainly
> Dijkstra-inspired)
> ...
> DO <label-1> FOREVER;
> DO <label-2> FOREVER;
> DO <label-3 FOREVER;
> ...
> IF <condition-1> THEN UNDO; % transfers control to just after
> END <label-3>
> IF <condition-2> THEN UNDO <label-2>; % control to after END
> <label-2>
> IF <condition-3> THEN UNDO *; % control to outermost DO within
> procedure
> END <label-3>;
> END <label-2>;
> END <label-1>;
>
> You can certainly EXIT the "innermost" PERFORM in COBOL, but there's no
> provision to EXIT, say, the fifth nested PERFORM level above you in the
> hierarchy.
>
> -Chuck Stevens
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:yBfzf.123644$Es3.36473@fe03.news.easynews.com...

IMO this would be like ALTER---a facility that if used would lead to
unreadable spaghetti code. I prefer to do PERFORMs out of line and provide
each with an exit mechanism by setting/unsetting a switch. See Murach, Noll
et al. for examples. It is not difficult to set several switches at once to
bounce up several levels e.g.,
IF (condition)
MOVE "Y" TO LEVEL-5-SWITCH LEVEL4-SWITCH LEVEL-3-SWITCH
ELSE
(rest of performed subroutine).
But I question the soundness of such logic.

Be careful what you ask for.
--
John Culleton
Able Indexers and Typesetters

Tiberiu Gociu

2006-01-18, 9:55 pm

Could be a possible solution for you?

Cheers,
Tibi

CODE-ROUTINE.
IF FOUND-SUBCODE
PERFORM SUBCODE-ROUTINE THRU EX-SUBCODE-ROUTINE
PERFORM WRITE-RESULTS THRU EX-WRITE-RESULTS
END-IF
EX-CODE-ROUTINE.
EXIT.
...
SUBCODE-ROUTINE.
...
IF FINISHED-SUBCODE
PERFORM CHECK-INVENTORY THRU EX-CHECK-INVENTORY
PERFORM ADD-TO-BIN
END-IF.
EX-SUBCODE-ROUTINE.
EXIT.
....
CHECK-INVENTORY.
...
IF NEED-TO-EXIT
GO TO EX-CHECK-INVENTORY
END-IF.
....
EX-CHECK-INVENTORY.
EXIT.

Howard Brazee

2006-01-18, 9:55 pm

On 18 Jan 2006 08:31:11 -0800, "Tiberiu Gociu"
<tiberiu.gociu@gmail.com> wrote:

>Could be a possible solution for you?

The use of exit paragraphs (which I thought I was through with) is a
partial solution. To pick the correct level of exits, I would need
switches.

A better solution would be a labeled EXIT PERFORM statement.

Chuck Stevens

2006-01-18, 9:55 pm

Top post; no more below.

As to the issue of "spaghetti" code resulting from PERFORM exits other than
from the most immediate one, I'd have to agree; I wasn't arguing for such a
mechanism in COBOL, only pointing out that there are languages that have
them.

Note that the *only* "loop control" mechanism available in Burroughs B1000
SDL/UPL were the procedure call and the DO FOREVER / UNDO / END mechanism.
There was no GO TO in the language at all. In that environment, "spaghetti
code" is a non-issue.

-Chuck Stevens

"John Culleton" <john@wexfordpress.com> wrote in message
news:6qqdncqi749t-VPenZ2dnUVZ_tadnZ2d@adelphia.com...
> Chuck Stevens wrote:
>
>
> IMO this would be like ALTER---a facility that if used would lead to
> unreadable spaghetti code. I prefer to do PERFORMs out of line and
> provide
> each with an exit mechanism by setting/unsetting a switch. See Murach,
> Noll
> et al. for examples. It is not difficult to set several switches at once
> to
> bounce up several levels e.g.,
> IF (condition)
> MOVE "Y" TO LEVEL-5-SWITCH LEVEL4-SWITCH LEVEL-3-SWITCH
> ELSE
> (rest of performed subroutine).
> But I question the soundness of such logic.
>
> Be careful what you ask for.
> --
> John Culleton
> Able Indexers and Typesetters

Chuck Stevens

2006-01-18, 9:55 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:p0sss1p31ovm46qj1mkt43erl1etal90jk@
4ax.com...
>
> The use of exit paragraphs (which I thought I was through with) is a
> partial solution. To pick the correct level of exits, I would need
> switches.
>
> A better solution would be a labeled EXIT PERFORM statement.

First off, EXIT PERFORM is usable only with an "inline" PERFORM. J4
discussed the idea of extending it to out-of-line PERFORMs in the 2008 draft
and rejected the idea as too risky amd too much like GO TO.

But let's presume the standard did allow an EXIT PERFORM outside the context
of PERFORM ... END-PERFORM (our COBOL74 compiler, lacking inline PERFORMs,
has exactly this capability).

Because PERFORM ... THRU is still valid COBOL, the syntax for a "labelled
EXIT PERFORM" would have to allow the specification of both the start and
the end of the PERFORM range. That's starting to look really clumsy. And
beyond that, implementors would need to provide a mechanism to maintain some
encoded identification of both the start and end points of every active
PERFORM so that the specified range could be checked against EXIT PERFORMs
encountered at execution time.

If a labelled EXIT PERFORM statement were executed, and the end-points
specified don't match any of the PERFORMs that are currently "active", what
is the appropriate result? Other EXITs are treated as CONTINUE if they
appear "out of context", but that leads to a nightmarish risk of unexpected
results at execution time.

Personally, I think labelled EXIT PERFORM would raise more problems than it
would solve. Even EXIT PERFORM <integer>, where <integer> is the number of
levels to "exit", might be easier to define and less prone to errors , but
I'd be *really* surprised if very many people on this forum thought that
would be a fundamental improvement to COBOL's syntax!

-Chuck Stevens

Michael Wojcik

2006-01-18, 9:55 pm

[Reordered.]

In article <yBfzf.123644$Es3.36473@fe03.news.easynews.com>, "William M. Klein" <wmklein@nospam.netcom.com> writes:
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:dnnqs1tjutcc64coojpi0k06g2jrlopf38@
4ax.com...
> In the '02 Standard and some current implementations (but alas NOT IBM's).
>
> Exit PERFORM (cycle)

I don't think that's what Howard's looking for - he wrote "multi-
layer", which suggests that he wants something like Java's "labelled
break" and "labelled continue".

EXIT PERFORM is equivalent to an unlabelled break, and EXIT PERFORM
CYCLE to an unlabelled continue: they quit or move immediately to the
next iteration, respectively, of the innermost in-line perform. (For
Java, that would be innermost for, while, or do.)

A labelled break or continue, on the other hand, operates at the
scope of the so-labelled looping construct. For example:

while (a) {
b_loop: while (b) {
while (c) {
break b_loop;
}
}
}

The "break b_loop" will exit both the "c" loop and the "b" loop
and go all the way back to the "a" loop.

--
Michael Wojcik michael.wojcik@microfocus.com

I will shoue the world one of the grate Wonders of the world in 15
months if Now man mourders me in Dors or out Dors
-- "Lord" Timothy Dexter, _A Pickle for the Knowing Ones_

Defaultuser

2006-01-19, 3:55 am

"Howard Brazee" <howard@brazee.net> wrote in message
news:p0sss1p31ovm46qj1mkt43erl1etal90jk@
4ax.com...
> On 18 Jan 2006 08:31:11 -0800, "Tiberiu Gociu"
> <tiberiu.gociu@gmail.com> wrote:
>
>
> The use of exit paragraphs (which I thought I was through with) is a
> partial solution. To pick the correct level of exits, I would need
> switches.
>
> A better solution would be a labeled EXIT PERFORM statement.

You just do a series of SETS and UNSETS (INITIALIZE the COND) - it means an
extra check....but you already have the check on the lowest loop
anyway....so it's a check on outer loops which is negligible.

01 LABEL PIC X(01) VALUE ' '.
88 LABEL-A VALUE 'A'.
88 LABEL-B VALUES 'A','B' .

88 LABEL-C VALUES 'A','B','C' .

PERFORM <paragraph-A> UNTIL <your-A-cond> OR LABEL-A
INITIALIZE LABEL
PERFORM <paragraph-B> UNTIL <your-B-cond> OR LABEL-B
INITIALIZE LABEL
PERFORM <paragraph-C> UNTIL <your-C-cond> OR LABEL-C
INITIALIZE LABEL
EVALUATE <exit-perform-cond>
WHEN <exit-c>
MOVE 'C' TO LABEL
WHEN <exit-b>
MOVE 'B' TO LABEL
WHEN <exit-a>
MOVE 'A' TO LABEL
END-EVALUATE
END-PERFORM
END-PERFORM
END-PERFORM

I was bored and had 5 mins to kill....not sure if this is useful or not (or
even if it works - like I said, I only have 5 mins and I don't code COBOL
too much these days). I assume that setting a return flag and a paragraph
exit is not a big deal....

I understand why you like the labeled break as it's a lot more flexible;
however, in all my years of looking at Java code, I've not seen it used more
than a handful (I actually only recall one and it was totally unecessary) -
then again I haven't seen a whole lot of close nested performs like this
either...and where I have they just have more conditions on the for(;;).

If nothing else, I think that this code looks like someone who thinks more
in C than anything.

DU

Michael Wojcik

2006-01-19, 6:55 pm

In article <dqlv91$or$1@si05.rsvl.unisys.com>, "Chuck Stevens" <charles.stevens@unisys.com> writes:
>
> Personally, I think labelled EXIT PERFORM would raise more problems than it
> would solve.

If it was restricted to inline PERFORM, I don't see any problem; that
is, it doesn't seem to me to be any more pernicious than the average
construct now available. Certainly it can be abused, but what can't?

I'll note that labelled break and continue in Java have not caused
any particular grief in that language. (Frankly, as far as code
readability goes, I think Java's worst problem is the inclination
among many of its practitioners to write lines of a hundred
characters or so. The whitespace shortage is over, folks.)

> Even EXIT PERFORM <integer>, where <integer> is the number of
> levels to "exit", might be easier to define and less prone to errors

That's worse, IMO, because it's fragile. If code is refactored and a
level is added or removed to a nested PERFORM with a multilevel EXIT
PERFORM, then that magic number is suddenly wrong.

And numbered EXIT PERFORM is just labelled EXIT PERFORM with
potentially meaningful labels dropped in favor of forcing the code
maintainer to count levels. Make the compiler do the work, not the
programmer.

(If I were writing a language, actually, I think I'd require *all*
loops to be labelled, and the loop terminator would have to specify
the label. If the programmer is putting in a loop, it should be a
loop over something; let's make that explicit.)

--
Michael Wojcik michael.wojcik@microfocus.com

Thanks for your prompt reply and thanks for your invitatin to your
paradise. Based on Buddihism transmigration, I realize you, European,
might be a philanthropist in previous life! -- supplied by Stacy Vickers

Chuck Stevens

2006-01-19, 6:55 pm

If you're restricting "labelled EXIT PERFORM" to *inline* PERFORM
statements, it seems to me that the distinction between a "labelled" PERFORM
and an "unlabelled" PERFORM is precisely that the former has at least one
label, and that in turn identifies it as an *out-of-line* PERFORM, whereas
the "in-line" PERFORM does NOT have a label.

Taking the simplest cases:

PERFORM X. *> out-of-line PERFORM
PERFORM (statements from paragraph or section X) END-PERFORM. *> inline
PERFORM

Given that the "label" of a "labelled inline PERFORM" can't go after the
keyword PERFORM (otherwise it's a label already!), how do you propose to
differentiate a "labelled inline PERFORM" from an "out-of-line PERFORM"?

From the other side, if what you want to do is "EXIT PERFORM IT", what's the
syntax of the inline PERFORM statement from which you want to EXIT? Where
does "IT" go in the PERFORM statement, given that "PERFORM IT." is a valid
statement if IT is a paragraph-name or a section-name? I only see one
place for the "label" of a "labelled PERFORM", and that's immediately after
the keyword.

The only way I see to do this is to differentiate "PERFORM IT CONTINUE."
from "PERFORM IT CONTINUE END-PERFORM", and in the case that "IT" exists as
a paragraph-name or section-name in the program, that leads to the two
statements doing two ENTIRELY different things. I don't think that's such a
terrific idea, frankly!

COBOL *has* labelled loops, so long as you use out-of-line PERFORM!

-Chuck Stevens

"Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:dqor0j0237t@news3.newsguy.com...
>
> In article <dqlv91$or$1@si05.rsvl.unisys.com>, "Chuck Stevens"
> <charles.stevens@unisys.com> writes:
>
> If it was restricted to inline PERFORM, I don't see any problem; that
> is, it doesn't seem to me to be any more pernicious than the average
> construct now available. Certainly it can be abused, but what can't?
>
> I'll note that labelled break and continue in Java have not caused
> any particular grief in that language. (Frankly, as far as code
> readability goes, I think Java's worst problem is the inclination
> among many of its practitioners to write lines of a hundred
> characters or so. The whitespace shortage is over, folks.)
>
>
> That's worse, IMO, because it's fragile. If code is refactored and a
> level is added or removed to a nested PERFORM with a multilevel EXIT
> PERFORM, then that magic number is suddenly wrong.
>
> And numbered EXIT PERFORM is just labelled EXIT PERFORM with
> potentially meaningful labels dropped in favor of forcing the code
> maintainer to count levels. Make the compiler do the work, not the
> programmer.
>
> (If I were writing a language, actually, I think I'd require *all*
> loops to be labelled, and the loop terminator would have to specify
> the label. If the programmer is putting in a loop, it should be a
> loop over something; let's make that explicit.)
>
> --
> Michael Wojcik michael.wojcik@microfocus.com
>
> Thanks for your prompt reply and thanks for your invitatin to your
> paradise. Based on Buddihism transmigration, I realize you, European,
> might be a philanthropist in previous life! -- supplied by Stacy Vickers

Chuck Stevens

2006-01-19, 6:55 pm

"Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:dqor0j0237t@news3.newsguy.com...

> (If I were writing a language, actually, I think I'd require *all*
> loops to be labelled, and the loop terminator would have to specify
> the label.

> If the programmer is putting in a loop, it should be a
> loop over something; let's make that explicit.)

Note that in the language I cited earlier -- B1000 SDL/UPL -- there's only
one "sub-procedure" structure, and that's the DO ... END pair. The only
*loop* in the language is a variation on that -- DO FOREVER ... END, with IF
.... UNDO taking you out of the loop.

> If the programmer is putting in a loop, it should be a
> loop over something; let's make that explicit.)

Well, let's see. I know -- let's add "PERFORM X THRU Y" to the language.
That way, it'd be explicit what you're looping over -- it's whatever you
execute between the time you start at X and the time you end up at Y.
Wouldn't that be neat??? Oh ... wait ... ;-)

-Chuck Stevens

Frank Swarbrick

2006-01-19, 6:55 pm

Michael Wojcik<mwojcik@newsguy.com> 01/19/06 12:58 PM >>>
>
>(If I were writing a language, actually, I think I'd require *all*
>loops to be labelled, and the loop terminator would have to specify
>the label. If the programmer is putting in a loop, it should be a
>loop over something; let's make that explicit.)

I've been designing a language in my head. (Am I the only one who does
this?) I'll add this to it's specification. :-)

Frank

Howard Brazee

2006-01-20, 9:55 pm

On Thu, 19 Jan 2006 16:57:21 -0700, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:

I like it.
[color=darkred]
>I've been designing a language in my head. (Am I the only one who does
>this?) I'll add this to it's specification. :-)

I do it as well. Sometimes I fantasize about how I would have
changed CoBOL if I were writing it back when.

I never thought about designing languages until I bought two languages
for my Atari 800, Forth, and Action!. Action! was in a cartridge
and it was designed by someone who was into the theory of languages. I
thought that was

, to actually control the whole language and see
it working.

Michael Wojcik

2006-01-20, 9:55 pm

In article <dqoui8$1pkl$1@si05.rsvl.unisys.com>, "Chuck Stevens" <charles.stevens@unisys.com> writes:
> If you're restricting "labelled EXIT PERFORM" to *inline* PERFORM
> statements, it seems to me that the distinction between a "labelled" PERFORM
> and an "unlabelled" PERFORM is precisely that the former has at least one
> label, and that in turn identifies it as an *out-of-line* PERFORM, whereas
> the "in-line" PERFORM does NOT have a label.

"Labelled EXIT PERFORM", as I described it, would have to include new
syntax for labelling inline PERFORM.

Note that I'm not actually advocating this addition to the language,
just noting how it could be done in a manner equivalent to what Java
has.

--
Michael Wojcik michael.wojcik@microfocus.com

She felt increasingly (vision or nightmare?) that, though people are
important, the relations between them are not, and that in particular
too much fuss has been made over marriage; centuries of carnal
embracement, yet man is no nearer to understanding man. -- E M Forster

Chuck Stevens

2006-01-20, 9:55 pm

"Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:dqrc8e02csv@news1.newsguy.com...

> "Labelled EXIT PERFORM", as I described it, would have to include new
> syntax for labelling inline PERFORM.

Well, that's exactly my point. Where do you put a "label" in an inline
PERFORM without turning it into an out-of-line PERFORM and without
introducing ambiguities when the label exists both as a "perform label" and
a paragraph/section name?

> Note that I'm not actually advocating this addition to the language,
> just noting how it could be done in a manner equivalent to what Java
> has.

I agree, you didn't advocate it; others seem to be of the opinion that it'd
be a worthwhile addition, and my response to that is that I think it's a Bad
Idea (and not merely Not a Good Idea). There's noplace to put the label in
the syntax of an inline PERFORM without simultaneously introducing semantic
and/or syntactic ambiguities.

-Chuck Stevens

Michael Wojcik

2006-01-20, 9:55 pm

In article <dqp60u$1u5l$1@si05.rsvl.unisys.com>, "Chuck Stevens" <charles.stevens@unisys.com> writes:
> "Michael Wojcik" <mwojcik@newsguy.com> wrote in message
> news:dqor0j0237t@news3.newsguy.com...
>
>
>
> Well, let's see. I know -- let's add "PERFORM X THRU Y" to the language.
> That way, it'd be explicit what you're looping over -- it's whatever you
> execute between the time you start at X and the time you end up at Y.
> Wouldn't that be neat??? Oh ... wait ... ;-)

That's not what I meant by "loop over" - I was referring to the loop
invariant, not the body of the loop. A loop notionally operates over
a collection; it says "for each of these things do the following", or
"as long as there are such things do the following", where other
invariants (eg "flag X is not set") can be generalized as virtual
collections (eg "the set of items which satisfy the predicate 'arrived
while not X'").

I'd like to see a language encourage associating each loop with the
collection it applies to.

The idea would be to move toward literate programming, with more of
the program semantics captured in the syntax of the language, where
it could be automatically verified. It's the same principle that led
to Python's use of whitespace to indicate scope - the shape of the
program represents its control flow - but that doesn't scale well
(large scoping constructs are difficult to verify visually).

Then, if the language supports literate programming properly, source
code becomes a mix of structured descriptive text and code, with
concrete references between the two; and it's easy to create a single
toolchain that can process both.

(And if I were writing a language, its syntax wouldn't look much like
COBOL. Or C. Or even LISP or Forth or APL. We already have plenty
of all of those.)

--
Michael Wojcik michael.wojcik@microfocus.com

Painful lark, labouring to rise!
The solemn mallet says:
In the grave's slot
he lies. We rot. -- Basil Bunting

Michael Wojcik

2006-01-20, 9:55 pm

In article <43anb2F1m3q2cU1@individual.net>, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> writes:
>
> I've been designing a language in my head. (Am I the only one who does
> this?)

It seems like the only suitable place for designing a language, but
with some you really have to wonder... :-)

I've been toying with programming language ideas at least since I
was exposed to functional languages as an undergraduate. Learning
things like compiler design and implementation didn't discourage the
habit. And I graduated from a program that exposed us to quite a
range of languages: Pascal, C, VAX Assembler, LISP, Scheme, SML,
Modula-2, COBOL, FORTRAN, various scripting languages, and probably
some others I'm forgetting. It's easy to get the language bug that
way.

And if you learn about Turing-completeness and Kolmogorov complexity
equivalence classes, and you understand that, say, COBOL and Ocaml
can be used to express all the same programs, and that those programs
can be reduced to approximately the same size for a given problem,
regardless of language, I think that just makes it all the more
interesting: there are no computing-theoretic grounds on which to
prefer one (TC) language over another, so all the other possible
reasons, like elegance and readability, become all-important.

--
Michael Wojcik michael.wojcik@microfocus.com

The way things were, were the way things were, and they stayed that way
because they had always been that way. -- Jon Osborne

Howard Brazee

2006-01-20, 9:55 pm

On Fri, 20 Jan 2006 11:36:57 -0800, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>I agree, you didn't advocate it; others seem to be of the opinion that it'd
>be a worthwhile addition, and my response to that is that I think it's a Bad
>Idea (and not merely Not a Good Idea). There's noplace to put the label in
>the syntax of an inline PERFORM without simultaneously introducing semantic
>and/or syntactic ambiguities.

The syntax would have to be changed.

Example

LABEL INNER PERFORM UNTIL IS-TRUE
LABEL MIDDLE PERFORM UNTIL X = 3
PERFORM UNTIL MY-EOF
PERFORM OUTSIDE-PARAGRAPH
IF FOUND-IT EXIT MIDDLE
END-IF
END-PERFORM
END-PERFORM
END-PERFORM.

Other constructions would need to be considered if this functionality
was to be added to the language for instance, if we had that, this
should be optional:

LABEL INNER PERFORM UNTIL IS-TRUE
LABEL MIDDLE PERFORM UNTIL X = 3
PERFORM UNTIL MY-EOF
PERFORM OUTSIDE-PARAGRAPH
IF FOUND-IT EXIT MIDDLE
END-IF
END-PERFORM
END-PERFORM MIDDLE
END-PERFORM INNER

Howard Brazee

2006-01-20, 9:55 pm

On 20 Jan 2006 19:17:48 GMT, mwojcik@newsguy.com (Michael Wojcik)
wrote:

>(And if I were writing a language, its syntax wouldn't look much like
>COBOL. Or C. Or even LISP or Forth or APL. We already have plenty
>of all of those.)

Yes, but you could sell your new language if it was similar enough to
a popular language to make migration easy.

e.g. C -> C++ -> Java

Chuck Stevens

2006-01-20, 9:55 pm

"Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:dqrd0s02m9d@news2.newsguy.com...

> That's not what I meant by "loop over" - I was referring to the loop
> invariant, not the body of the loop. A loop notionally operates over
> a collection; it says "for each of these things do the following", or
> "as long as there are such things do the following", where other
> invariants (eg "flag X is not set") can be generalized as virtual
> collections (eg "the set of items which satisfy the predicate 'arrived
> while not X'").
>
No, I disagree, not in COBOL PERFORM in general. Except in the programmer's
mind there's no required relationship between the "iteration" logic, if it
exists, and the "terminating condition".
PERFORM VARYING A-COUNTER FROM 1 BY 1
UNTIL FUNCTION TODAYS-DATE (1:4) IS EQUAL TO 2008
<some sequence of statements>
END-PERFORM
which, presuming it doesn't encounter an INTEGER OVERFLOW fault or an EXIT
PERFORM, should "stay in control" until very, very early in the morning of
January 1, 2008 irrespective of the value of the loop counter or, for that
matter, the sequence of imperative statements. What's the relationship
between the value of A-COUNTER and the value of TODAYS-DATE? None.

Presuming that the object of the VARYING clause has anything syntactically
or semantically to do with what the UNTIL clause checks is not a good idea.
It may, it may not, that's up to the programmer.

> I'd like to see a language encourage associating each loop with the
> collection it applies to.

What if a "loop" doesn't apply to a "collection" as you describe it?

> The idea would be to move toward literate programming, with more of
> the program semantics captured in the syntax of the language, where
> it could be automatically verified.

I honestly don't know what you mean by that. But it seems to me that in
order to do something like this you'd have to *reduce* the capabilities of
the language first, requiring some sort of relationship between the
"iteration" and the "terminating condition". Implementors may *optimize*
for those cases in which such a relationship exists, but have to handle the
cases in which it doesn't all the same. Since eliminating a fundamental
aspect of PERFORM that's been there for, oh, say, four-and-a-half decades is
arguably impractical, such limitations become a matter of personal style,
not a matter of proscription by the standard.

Pascal, for example, has FOR (which implies a relationship between the
iterand and thereminating condition) alongside REPEAT and WHILE (which do
not). COBOL's PERFORM covers all three of these, along with the equivalent
of a procedure call.

-Chuck Stevens

Howard Brazee

2006-01-20, 9:55 pm

On 20 Jan 2006 19:32:29 GMT, mwojcik@newsguy.com (Michael Wojcik)
wrote:

>
>It seems like the only suitable place for designing a language, but
>with some you really have to wonder... :-)

I bet not many of us have designed a language in his head.

Howard Brazee

2006-01-20, 9:55 pm

On Fri, 20 Jan 2006 13:57:13 -0700, Howard Brazee <howard@brazee.net>
wrote:

>
>I bet not many of us have designed a language in his head.

That is in Frank's head.

Richard

2006-01-20, 9:55 pm

> "Labelled EXIT PERFORM", as I described it, would have to include new
> syntax for labelling inline PERFORM.

Perhaps something like:

PERFORM UNTIL A-Exit
PERFORM UNTIL A-Exit OR B-Exit
....
IF ... SET A-Exit
ELSE IF .... SET B-Exit
ELSE
do stuff
END-IF
END-IF
END-PERFORM
END-PERFORM

No wait, you can do that now. No need for any new syntax. Technically
A-Exit and B-Exit are conditionals, but think of them as exit points
and you are done.

Chuck Stevens

2006-01-20, 9:55 pm

Interesting approach, Howard. A bit clumsy-looking, but workable. I don't
see any holes. However, I haven't thought through the repercussions of
having a user-defined word immediately after a scope terminator.

I do like the symmetry of having explicit scope terminators that identify
the label for labelled PERFORMs in your second example, and if this were
proposed as a standard enhancement I'd suggest that <label> as part of
END-PERFORM <label> to terminate LABEL <label> PERFORM would be best as
mandatory (assuming no problems with a user-defined word there). Having
them syntactically optional offers no value-add that isn't available with
inline comments already.

-Chuck Stevens

"Howard Brazee" <howard@brazee.net> wrote in message
news:7nf2t19hq6dh3tuu0qcu0ocudhmlieon0e@
4ax.com...
> On Fri, 20 Jan 2006 11:36:57 -0800, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
>
> The syntax would have to be changed.
>
> Example
>
> LABEL INNER PERFORM UNTIL IS-TRUE
> LABEL MIDDLE PERFORM UNTIL X = 3
> PERFORM UNTIL MY-EOF
> PERFORM OUTSIDE-PARAGRAPH
> IF FOUND-IT EXIT MIDDLE
> END-IF
> END-PERFORM
> END-PERFORM
> END-PERFORM.
>
>
> Other constructions would need to be considered if this functionality
> was to be added to the language for instance, if we had that, this
> should be optional:
>
> LABEL INNER PERFORM UNTIL IS-TRUE
> LABEL MIDDLE PERFORM UNTIL X = 3
> PERFORM UNTIL MY-EOF
> PERFORM OUTSIDE-PARAGRAPH
> IF FOUND-IT EXIT MIDDLE
> END-IF
> END-PERFORM
> END-PERFORM MIDDLE
> END-PERFORM INNER
>

Richard

2006-01-20, 9:55 pm

> Yes, but you could sell your new language if it was similar enough to
> a popular language to make migration easy.

> e.g. C -> C++ -> Java

You use the word 'sell' as if money would change hands. I did pay for
a couple of C compilers over 20 years ago (and I still use them) and a
C++ or two, but free high quality compilers are available for dozens of
languages including those 3.

The popular languages are not so because of their syntax (eg see Perl),
but because of the rich libraries and components that are available to
implement the task with the minimum of source code.

Howard Brazee

2006-01-20, 9:55 pm

On 20 Jan 2006 13:41:15 -0800, "Richard" <riplin@Azonic.co.nz> wrote:

>
>
>You use the word 'sell' as if money would change hands.

I didn't mean to.

>I did pay for
>a couple of C compilers over 20 years ago (and I still use them) and a
>C++ or two, but free high quality compilers are available for dozens of
>languages including those 3.
>
>The popular languages are not so because of their syntax (eg see Perl),
>but because of the rich libraries and components that are available to
>implement the task with the minimum of source code.

Success is easier if:
a. The product works well.
b. People can learn to use the product easily.
c. The costs are low to get try it.

Peter Lacey

2006-01-20, 9:55 pm

Richard wrote:
> The popular languages are not so because of their syntax (eg see Perl),
> but because of the rich libraries and components that are available to
> implement the task with the minimum of source code.

I'd add that languages are also popular because they were taught at the
time when people determined their preferences. If I had my druthers,
RPG would be a very popular language (not just on AS400's): it was the
second language I learned. (It was and is very useful in its own proper
usage so I'm not just being parochial).

PL

Richard

2006-01-20, 9:55 pm

> Success is easier if:
> a. The product works well.
> b. People can learn to use the product easily.
> c. The costs are low to get try it.

There are dozens of languages that meet those criteria yet aren't
'successful'.

Arguably, some successful languages don't meet those criteria (esp. b).

Richard

2006-01-20, 9:55 pm

> If I had my druthers, RPG would be a very popular language

I always thought of RPG as a number of different 'things', I am not
sure that I would call all of them 'languages'. I did look at ICL
(Univac) 1004 RPG to replace the system that was using this, and
managed to avoid ICL's RPG II for the 2903 range. Some programmers
attempted to use it for a system that I was responsile for when I
worked at ICL. After a w

or two of them failing to work correctly I
had to write the programs myself in Cobol overnight to get them live
the next day.

I suspect that AS400 RPG is quite different, even from S3 RPG, I would
hope so.

Rosa Fischer

2006-01-22, 9:55 pm

Howard Brazee schrieb:
> It is interesting that Java, where the word GOTO is reserved but not
> used, it has a label and a GoTo equivalent to tell us how to exit a
> multi-layer iteration (perform loop).
>
> I wish we had an equivalent in CoBOL.
>
>
You could use either "EXIT PARAGRAPH" oder "EXIT SECTION" in COBOL.

Rosa

Michael Wojcik

2006-01-23, 6:55 pm

In article <1137793275.462165.208330@g14g2000cwa.googlegroups.com>, "Richard" <riplin@Azonic.co.nz> writes:
>
> The popular languages are not so because of their syntax (eg see Perl),
> but because of the rich libraries and components that are available to
> implement the task with the minimum of source code.

That may well be one factor that contributes to some languages'
popularity, but C, for example, has been extremely successful despite
the fact that the standard library is very small and primitive. Even
POSIX, the most widely supported API outside the C standard for C
programming, is quite primitive by comparison with, say, the Java
class library, or the C++ standard library.

I suspect C's popularity is a combination of several factors, each of
which had somewhat different historical development:

- It caters to certain programming styles, particularly "quick and
dirty", and it imposes few restrictions on the programmer. That makes
it emotionally appealing for hackers, who want to write some code and
see it run.

- Free implementations are widely available, which made it one of the
first languages available on many platforms.

- Since the standard library is small, the runtime is small as well,
which makes it more likely to be installed by default on target systems,
or if not, not a large inconvenience for users.

- Because so much in the language is implementation-defined or undefined,
most portation problems are the responsibility of the programmer, not the
language implementor. Paradoxically, that appeals to some programmers
looking to port to many platforms, because it means they're not dependent
on implementors - they can handle portation issues themselves.

- A great deal of C source code is freely available. C is not very
well-suited to code reuse, so relatively little of this can be taken as
"components", and in fact there's a tremendous amount of reinvention in
C programming. (I've read a *lot* of C source over the years, and this
is almost universally true; I regularly see C programmers reinventing
even functions from the standard library!) It does mean, though, that
with a C implementation you get easy access to a huge array of software,
particularly tools, and that tends to draw people into C.

- Thanks to its extensive use in Unix, C gained a reputation as a
language for system programming.

Clearly, many other popular languages - such as COBOL - don't share
many of these attributes, and so are popular for entirely different
reasons. I don't think we can point to any one thing as the magic
formula for a language's success.

For that matter, there are languages with rich libraries, high-level
functionality, and excellent expressive capability that have never
won significant market share. Common LISP and OCaml are good
examples. Common LISP is a standardized language which permits very
simple prototyping and includes a full object system; it has a steep
(ie fast) learning curve and programmers can quickly become very
productive with it. Large commercial LISP projects have been
successful, but there are few of them.

OCaml is tremendously expressive and modern implementations are very
fast - "natural" implementations of compute-intensive tasks in OCaml
sometimes beat the "natural" implementations of the same tasks in C.
More importantly, OCaml is very safe; it's a strictly-typed functional
language with built-in memory management that's amenable to proofs of
correctness and secure programming techniques. Yet almost no one
uses it in commercial development. I could speculate why, but I think
really it comes down to a host of irrational factors: comfort level
and familiarity for developers and management; a reluctance to move
away from the languages used for existing code bases, even when those
are fraught with bugs; and chance - some languages catch the eyes of
tastemakers and others do not.

--
Michael Wojcik michael.wojcik@microfocus.com

This book uses the modern technology to explain the phenomemon in the world
of Japanese animation. If you love anime so much, you'd better read this.
After you read it, you may agree that is destroying the dream of the child.
Needs Chinese viewing system. -- The Goodboy Scientific

Howard Brazee

2006-01-23, 6:55 pm

On 20 Jan 2006 17:57:35 -0800, "Richard" <riplin@Azonic.co.nz> wrote:

>
>There are dozens of languages that meet those criteria yet aren't
>'successful'.
>
>Arguably, some successful languages don't meet those criteria (esp. b).

Easier just means easier.

Howard Brazee

2006-01-23, 6:55 pm

On Fri, 20 Jan 2006 17:59:57 -0600, Peter Lacey <lacey@mts.net> wrote:

>I'd add that languages are also popular because they were taught at the
>time when people determined their preferences. If I had my druthers,
>RPG would be a very popular language (not just on AS400's): it was the
>second language I learned. (It was and is very useful in its own proper
>usage so I'm not just being parochial).

One trouble with RPG is a trouble with lots of languages. I've
worked in shops where it was the hammer that made every problem look
like a nail. At one time it was an RPG only shop and RPG was used
for solutions that RPG was quite unsuited for.

In any shop, we have people who know how to use one tool. When you
can use one tool, it doesn't matter if it is an appropriate tool for
the company - it is the tool you use.

You need a certain body of work for which a tool is appropriate in
order for it to be cost effective for the company to use.

One advantage Java has is that it doesn't cost much for a company to
start using it with web services. The kids that were just hired know
how to use it, and the software tools are cheap.

But let's say they want to start using CoBOL for a few reports. It's
not as cheap to find some kids who know how to use a cheap compiler.

Once a tool starts being used, it is easy to expand it to less
appropriate needs - because you already have the tools and the skills.

Howard Brazee

2006-01-23, 6:55 pm

On Sun, 22 Jan 2006 22:56:22 +0100, Rosa Fischer
<grforestcat@netscape.net> wrote:

>You could use either "EXIT PARAGRAPH" oder "EXIT SECTION" in COBOL.

The label in Java tells the loop within loop within loop within loop
how far to exit.

With CoBOL we need switches to do the same thing.

Michael Wojcik

2006-01-23, 6:55 pm

In article <k0g2t15o5b7cg6q28u75ckp7k4oq9o1ksr@4ax.com>, Howard Brazee <howard@brazee.net> writes:
> On 20 Jan 2006 19:17:48 GMT, mwojcik@newsguy.com (Michael Wojcik)
> wrote:
>
>
> Yes, but you could sell your new language if it was similar enough to
> a popular language to make migration easy.

Fortunately, if I were writing a language, I don't think popularity
would be one of my goals. We have enough popular languages already,
and for that matter unpopular but arguably superior ones. (I'd love
to drop all the C and C++ we use here in favor of OCaml. I bet we'd
reduce the bug rate by an order of magnitude, at least. It'll never
happen.)

--
Michael Wojcik michael.wojcik@microfocus.com

Even though there may be some misguided critics of what we're trying
to do, I think we're on the wrong path. -- Reagan

Michael Wojcik

2006-01-23, 6:55 pm

In article <dqre4p$7oq$1@si05.rsvl.unisys.com>, "Chuck Stevens" <charles.stevens@unisys.com> writes:
> "Michael Wojcik" <mwojcik@newsguy.com> wrote in message
> news:dqrc8e02csv@news1.newsguy.com...
>
>
> There's noplace to put the label in
> the syntax of an inline PERFORM without simultaneously introducing semantic
> and/or syntactic ambiguities.

I was thinking of something like Howard's proposal, with a new
keyword. Again, I wouldn't advocate that in COBOL's case - I'm not
generally a supporter of adding new keywords without very good
reason. But if 'twere done...

--
Michael Wojcik michael.wojcik@microfocus.com

It does basically make you look fat and naked - but you see all this stuff.
-- Susan Hallowell, TSA Security Lab Director, on "backscatter" scanners

Michael Wojcik

2006-01-23, 6:55 pm

In article <dqrhas$9ik$1@si05.rsvl.unisys.com>, "Chuck Stevens" <charles.stevens@unisys.com> writes:
> "Michael Wojcik" <mwojcik@newsguy.com> wrote in message
> news:dqrd0s02m9d@news2.newsguy.com...
>
> No, I disagree, not in COBOL PERFORM in general. Except in the programmer's
> mind there's no required relationship between the "iteration" logic, if it
> exists, and the "terminating condition".
> PERFORM VARYING A-COUNTER FROM 1 BY 1
> UNTIL FUNCTION TODAYS-DATE (1:4) IS EQUAL TO 2008
> <some sequence of statements>
> END-PERFORM
> which, presuming it doesn't encounter an INTEGER OVERFLOW fault or an EXIT
> PERFORM, should "stay in control" until very, very early in the morning of
> January 1, 2008 irrespective of the value of the loop counter or, for that
> matter, the sequence of imperative statements. What's the relationship
> between the value of A-COUNTER and the value of TODAYS-DATE? None.

That's the same error as your previous objection: you're conflating
the loop invariant and the loop body. "VARYING A-COUNTER" is
syntatically part of the loop control structure, but semantically it's
part of the loop body; it's no different from an "ADD 1 TO A-COUNTER"
in the body. It has no relevance to what I'm describing as "looping
over".

Formally, any loop (in a Deterministic Turing Machine, or simulation
thereof[1]) is a mapping (specifically a bijection) between an
ordered collection and a series of program states. The expression
of a loop in a particular language doesn't change that; it's what a
loop *is*.

In your example, your loop is looping over iterations until the
invariant predicate is no longer satisfied. "A-COUNTER" is no more
relevant than the phase of the moon. The fact that the loop's
domain collection - what it iterates over - is an indication that
either we lack information or the loop is not well-conceived. The
body of the loop might provide the former; for example, if it reads
and processes a record, then the loop becomes a loop over "records
available until 2008". If the loop simply performs some calculation
which is not sensitive to an external event (ie, which does not
specify an additional condition on the domain collection) then the
loop is degenerate; but it's still a loop over a collection, just
a poorly-specified one. (Namely, it's "iterations scheduled
by the CPU until 2008".)

> Presuming that the object of the VARYING clause has anything syntactically
> or semantically to do with what the UNTIL clause checks is not a good idea.
> It may, it may not, that's up to the programmer.

Nothing in what I wrote implied that the object of the VARYING
clause has anything to do with the loop's domain, and indeed it
does not.

>
> What if a "loop" doesn't apply to a "collection" as you describe it?

It has to. All loops can be reduced to such a formalism.

>
> I honestly don't know what you mean by that. But it seems to me that in
> order to do something like this you'd have to *reduce* the capabilities of
> the language first, requiring some sort of relationship between the
> "iteration" and the "terminating condition".

There is a relationship between iteration and "terminating condition"
(invariant): the latter determines whether the former occurs. That's
all that's necessary for what I describe, and it arises directly from
the essential formal structure of the loop.

> Pascal, for example, has FOR (which implies a relationship between the
> iterand and thereminating condition) alongside REPEAT and WHILE (which do
> not).

REPEAT and WHILE have the same relationship between iteration and
invariant as FOR does. What FOR adds is a bit of syntactic sugar that
places part of the body - the part that assigns a value to the counter
- in the syntax of the loop control structure. But formally that's
still part of the body; it doesn't change the formal mechanism a bit.

1. Obviously this formalism doesn't apply to a Nondeterministic TM,
because there "invariant" may not hold; nor does it apply to
"quantum computing" because superposition means multiple positions
in the "loop" phase space may be occupied simultaneously.

--
Michael Wojcik michael.wojcik@microfocus.com

Most people believe that anything that is true is true for a reason.
These theorems show that some things are true for no reason at all,
i.e., accidentally, or at random. -- G J Chaitin

Howard Brazee

2006-01-23, 6:55 pm

On 23 Jan 2006 14:16:13 GMT, mwojcik@newsguy.com (Michael Wojcik)
wrote:

>
>Fortunately, if I were writing a language, I don't think popularity
>would be one of my goals. We have enough popular languages already,
>and for that matter unpopular but arguably superior ones. (I'd love
>to drop all the C and C++ we use here in favor of OCaml. I bet we'd
>reduce the bug rate by an order of magnitude, at least. It'll never
>happen.)

It would be fun to create a language. But it would be more fun if
that language was actually *used*.

Rosa Fischer

2006-01-23, 6:55 pm

You can leave the inner loop with "EXTIT PARAGRAPH" and the next one
with "EXIT SECTION". But writing is easier than reading.

Rosa

Howard Brazee schrieb:
> On Sun, 22 Jan 2006 22:56:22 +0100, Rosa Fischer
> <grforestcat@netscape.net> wrote:
>
>
>
>
> The label in Java tells the loop within loop within loop within loop
> how far to exit.
>
> With CoBOL we need switches to do the same thing.

Howard Brazee

2006-01-23, 6:55 pm

On Mon, 23 Jan 2006 18:29:01 +0100, Rosa Fischer
<grforestcat@netscape.net> wrote:

>You can leave the inner loop with "EXTIT PARAGRAPH" and the next one
>with "EXIT SECTION". But writing is easier than reading.

Only if there are two loops.

Richard

2006-01-23, 6:55 pm

Michael Wojcik wrote:

[color=darkred]
> That may well be one factor that contributes to some languages'
> popularity, but C, for example, has been extremely successful despite
> the fact that the standard library is very small and primitive. ...

[...]

> ... It does mean, though, that
> with a C implementation you get easy access to a huge array of software,
> particularly tools, and that tends to draw people into C.

So you do agree with me ;-)

There were many languages avilable that had adherents, but with C you
could select from hundreds of diskettes of open source software to
provide most of a solution.

> More importantly, OCaml is very safe; it's a strictly-typed functional
> language with built-in memory management that's amenable to proofs of
> correctness and secure programming techniques. Yet almost no one
> uses it in commercial development.

No, they seem to prefer loosely typed dynamic OO scripting languages
such as Perl (yuk), PHP and Python (yay!).

> I could speculate why, but I think
> really it comes down to a host of irrational factors: comfort level
> and familiarity for developers and management; a reluctance to move
> away from the languages used for existing code bases, even when those
> are fraught with bugs; and chance - some languages catch the eyes of
> tastemakers and others do not.

And some have code or libraries available that do almost exactly what
is required with minimum effort.

Richard

2006-01-23, 6:55 pm

> You can leave the inner loop with "EXTIT PARAGRAPH" and the next one
> with "EXIT SECTION". But writing is easier than reading.

That could only be used if they were not in-line performs, if there
were exactly two levels, and if you were prepared to use a munted
structure in your programs.

I dislike all the new EXIT something statements, only EXIT PROGRAM is
acceptable to me. The others are all positionally sensitive. I write
code that can be moved from inside an on-line perform to its own
paragraph, or can be indented within an IF or ... withoutout having to
change the code.

EXIT PERFORM, EXIT PARAGRAPH and GO TO cannot be moved around in that
way and thus I do not use them. Using switches to exit (as in my
previous sample) works no matter how the code is physically arranged as
long as it retains the same logical structure. PERFORM THRU and PERFORM
sections also leads to unacceptable dependence on physical arrangement.
I have found from programming over several decades that any dependence
on physical arrangement prevents code reuse and requires too much
effort to avoid bugs.

HeyBub

2006-01-23, 6:55 pm

Howard Brazee wrote:
> On Mon, 23 Jan 2006 18:29:01 +0100, Rosa Fischer
> <grforestcat@netscape.net> wrote:
>
>
> Only if there are two loops.

If you need more than two loops are you loopy?

Pete Dashwood

2006-01-24, 3:55 am

"Howard Brazee" <howard@brazee.net> wrote in message
news:72u9t1dq4n1irk5io34t9pnlmpi09k0mdm@
4ax.com...
> On 23 Jan 2006 14:16:13 GMT, mwojcik@newsguy.com (Michael Wojcik)
> wrote:
>
>
> It would be fun to create a language. But it would be more fun if
> that language was actually *used*.

Well, Howard, you could always create a language and use it yourself...

(Hey, it works for Tony Dilworth :-))

Pete Dashwood

2006-01-24, 3:55 am

"Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:dr2ofd014s3@news4.newsguy.com...
>
> In article <k0g2t15o5b7cg6q28u75ckp7k4oq9o1ksr@4ax.com>, Howard Brazee
> <howard@brazee.net> writes:
>
> Fortunately, if I were writing a language, I don't think popularity
> would be one of my goals. We have enough popular languages already,
> and for that matter unpopular but arguably superior ones. (I'd love
> to drop all the C and C++ we use here in favor of OCaml. I bet we'd
> reduce the bug rate by an order of magnitude, at least. It'll never
> happen.)
>
Michael,

You are an experienced and highly competent member of a prestigious team. If
you really believe what you have written, why not prepare a case showing
what you expect the benefits would be and why you believe so?

I never heard of OCaml until I saw your posts, but I have enough respect for
your past postings to recognize that you are worth listening to. If I can
deduce that from occasionally browsing a newsgroup, why would the people who
work with you and manage you every day, not also be interested to hear your
opinion? (I sometimes remind my boss when he doesn't like what I tell him,
that he is payng to hear it, so he might as well think it over... :-))

I believe you may be abandoning the field before a shot is fired. You
believe you can't win, and there are certainly factors (like the
"unknownness" of the language) working against you, but if the benefits are
real, they represent real cost savings and management is duty bound to at
least hear your case. If OCaml can be easily "acquired" by existing
programmers and if it provides the benefits you believe it does, then why
not suggest a pilot study? Take a small project, estimate time and cost to
do it in the existing languages, and then actually do it in OCaml and see
how it stacks up. If you get someone else to work with you on that project
there are then 2 of you to spread the word...If it is successful it will
certainly arouse interest, and if it isn't...well, it was a pilot study...
:-) No real harm was done and we are better informed than we were...

It seems a pity to me that someone as useful as yourself would not have the
confidence to try and improve things where you believe they honestly could
be inproved. I bet you wouldn't hesitate to rewrite or redesign bad code or
architecture you came across...:-).

When you say "it'll never happen" there are two things to remember:

1. "never" is a VERY long time... :-)
2. Nothing happens without an idea first. You have an idea.

Even though you're not paying to read this :-) I would urge you to think it
over... :-)

Pete.

Peter Lacey

2006-01-24, 6:55 pm

Howard Brazee wrote:
>
> On Fri, 20 Jan 2006 17:59:57 -0600, Peter Lacey <lacey@mts.net> wrote:
>
>
> One trouble with RPG is a trouble with lots of languages. I've
> worked in shops where it was the hammer that made every problem look
> like a nail. At one time it was an RPG only shop and RPG was used
> for solutions that RPG was quite unsuited for.
>
You can hardly blame the language for that, though, can you? Especially
(as you note) that it's a problem with lots of languages).

> You need a certain body of work for which a tool is appropriate in
> order for it to be cost effective for the company to use.
>

That's just restating my point. Report Program Generator is very good at
generating reports and sequential processing generally. There is
definitely an upper limit of usefulness and complexity, to be sure,
beyond which RPG is not appropriate.

I've met quite a few programmers who HATE RPG (so they say). They used
it perhaps twice and then retreated to the simplicity of C in most
cases. Hardly a rigourous test!

PL

Howard Brazee

2006-01-24, 6:55 pm

On Tue, 24 Jan 2006 14:35:32 -0600, Peter Lacey <lacey@mts.net> wrote:

>
>I've met quite a few programmers who HATE RPG (so they say). They used
>it perhaps twice and then retreated to the simplicity of C in most
>cases. Hardly a rigourous test!

Odd choice. What RPG does well, C does poorly. What C does well,
RPG does poorly.

Michael Wojcik

2006-01-25, 6:55 pm

In article <72u9t1dq4n1irk5io34t9pnlmpi09k0mdm@4ax.com>, Howard Brazee <howard@brazee.net> writes:
> On 23 Jan 2006 14:16:13 GMT, mwojcik@newsguy.com (Michael Wojcik)
> wrote:
>
>
> It would be fun to create a language. But it would be more fun if
> that language was actually *used*.

I'm sure many people feel that way, and I suppose seeing my pet
project used would be pleasant, but for me its ideological purity is
more important. Even if no one used it I could still pretend I had
the high moral ground... :-)

And there are all those "esoteric" languages, such as the "Turing
Tarpit" languages like Unlambda that try to produce a Turing-complete
language with as few operators as possible, or the deliberately
perverse languages like INTERCAL. I don't think the inventors of
those languages - and there's a surprising number of them - intended
them to be popular.

It's interesting to speculate on what languages come close to the
sweet spot of elegant design and popularity. I'd nominate Ruby,
which has some very nice features and is quite big these days. OCaml
has some fans and has seen some commercial use. Even Javascript,
surprisingly, might be up there, as an example of a "convenient"
language (a typeless scripting language with a lot of built-in
functionality) which is nonetheless quite capable as a general-
purpose language (if performance isn't an issue) - and it's certainly
popular.

--
Michael Wojcik michael.wojcik@microfocus.com

I said, 'I need to put my soul into my work and it is well known that
computers haven't got a soul.' My father said, 'The Americans are working
on it.' -- Sue Townsend, _The Secret Diary of Adrian Mole, Aged 13 3/4_

Michael Wojcik

2006-01-25, 6:55 pm

In article <pap9t1pqtnkenk1rfodcg87pjaohbeu76i@4ax.com>, Howard Brazee <howard@brazee.net> writes:
>
> One advantage Java has is that it doesn't cost much for a company to
> start using it with web services. The kids that were just hired know
> how to use it, and the software tools are cheap. [...]
>
> Once a tool starts being used, it is easy to expand it to less
> appropriate needs - because you already have the tools and the skills.

I agree, and I think this also goes a long way to explaining C's
popularity. In the 1980s, there was a lot of open-source free
software (much of it public domain, ie completely unencumbered)
available, and C was the predominant language. (Obviously there is
still a great deal of open-source C around, but it's no longer as
dominant as it was in the '80s.) And C compilers were available free
(or bundled with the OS, so for no additional cost) for many platforms,
particularly various Unix flavors.

So many people would install C compilers so they could build some of
those useful free programs; and they'd start to learn C so they could
modify those programs; and then they'd start writing their own C
programs, because the language was already available; and so vendors
and free-software proponents were encouraged to make C compilers
available, since that's what many people already used.

Obviously there are other factors - it's easier to produce a quick-
and-dirty C compiler than a COBOL one, for example, because the
language is so much smaller and less ambitious, and so there are far
fewer features to implement. (Also the parser's a bit simpler,
though I don't believe that really has much influence on compiler
writers.) But "everything looks like a nail" does seem to be a major
influence.

--
Michael Wojcik michael.wojcik@microfocus.com

Unlikely prediction o' the day:
Eventually, every programmer will have to write a Java or distributed
object program.
-- Orfali and Harkey, _Client / Server Programming with Java and CORBA_

Michael Wojcik

2006-01-25, 6:55 pm

In article <1138044236.131727.197540@o13g2000cwo.googlegroups.com>, "Richard" <riplin@Azonic.co.nz> writes:
> Michael Wojcik wrote:
>
>
>
>
> So you do agree with me ;-)

Well, not exactly.

> There were many languages avilable that had adherents, but with C you
> could select from hundreds of diskettes of open source software to
> provide most of a solution.

There was (and is) a lot of C source available, true (see my response
to Howard on this topic). But I was actually referring to the fact
that with a C implementation you could build a lot of software that
was useful in itself, not as resources for your own C project.

In theory, there have long been many free libraries and code snippets
you could use to extend the standard C language in a more or less
portable fashion. In practice, though, for every C project I've seen
that uses, say, Berkeley DB to store data, I've seen ten that rely
directly on C's file I/O to implement their own (often not very well-
designed) database.

The history of C is a history of reinvention. Look at all the C APIs
available for providing GUIs under X11 (a key area for many applica-
tions which is not covered by the standard language), for example:
Xlib, Xtk, Xaw, Motif... And yet despite all of those, with their
often-overlapping functionality, we have many, many X11 C programs
that implement their own widget libraries. xrn, the newsreader I'm
using here, is one.

Contrast that with languages that have large standard or semi-standard
libraries, like Java or C++ (particularly since the 98 standard put
the STL in the standard library). libavl is readily available for
most C projects, but I see C programmers time and again implementing
their own tree structures. The competent contemporary C++ programmer,
on the other hand, will use a standard container for the vast majority
of applications.

There's a lot available for C, outside the standard language, but in
practice it does not see nearly as much use as similar facilities do
for other languages.

>
> No, they seem to prefer loosely typed dynamic OO scripting languages
> such as Perl (yuk), PHP and Python (yay!).

That doesn't explain the popularity of, say, C++.

>
> And some have code or libraries available that do almost exactly what
> is required with minimum effort.

Some do, for some tasks. But again I've seen countless lines of C++
struggling to perform what could be done with far less effort - and
far fewer bugs - in OCaml. I don't believe richness of already-
available functionality is really very prominent in commercial
language selection. It plays a role, but I'm not convinced it's a
major one in the industry as a whole.

--
Michael Wojcik michael.wojcik@microfocus.com

But I still wouldn't count out the monkey - modern novelists being as
unpredictable as they are at times. -- Marilyn J. Miller

Michael Wojcik

2006-01-25, 6:55 pm

In article <43m8tiF1og6p9U1@individual.net>, "Pete Dashwood" <dashwood@enternet.co.nz> writes:
> "Michael Wojcik" <mwojcik@newsguy.com> wrote in message
> news:dr2ofd014s3@news4.newsguy.com...
>
> You are an experienced and highly competent member of a prestigious team. If
> you really believe what you have written, why not prepare a case showing
> what you expect the benefits would be and why you believe so?
>
> I never heard of OCaml until I saw your posts, but I have enough respect for
> your past postings to recognize that you are worth listening to. If I can
> deduce that from occasionally browsing a newsgroup, why would the people who
> work with you and manage you every day, not also be interested to hear your
> opinion?

This is a good and interesting question (at least IMO), and worth a
serious answer. So this is a rather long post (and I certainly won't
be offended if people don't feel obliged to read all of it).

There are a number of factors that I think would prevent Micro Focus,
or even just one of the development groups here, from making this
sort of major switch. I think most organizations would find many of
them apply, so this doesn't reflect poorly on MF, in my opinion; it's
a pervasive situation. There are development teams with the
flexibility to switch languages, and I've seen anecdotes of that
happening successfully, but it's the exception rather than the rule.

Some of those factors are largely objective, and some are largely
subjective, but most have elements of both.

Here are some of the major ones:

- Schedules. While I do believe that it's very probable that a
language switch would pay off in faster development (due in part to
less time spent in debugging) in the long run, it has a very large
up-front time cost in retraining staff and reimplementing existing
functionality. Some of that can be amortized by using a phased
approach, but only to some extent - changing languages has to be
done in fairly large "chunks".

We can't just interrupt our development and release schedules for
months; customers are waiting for enhancements and fixes, and the
market moves along whether we do or not.

- Platforms. MF has to support a lot of platforms, some because of
their importance in the market and some for contractual reasons. To
move to a new language, we have to get an implementation of it for
every platform where we will be using it (so for every platform
where the rewritten components will be used) and verify that that
implementation is reliable. That can be surprisingly difficult, even
with, say, the free open-source OCaml compilers.

An anecdote: for some components, we are still obliged to support
platforms which don't have a standard-conforming C implementation.
The C standard is 16 years old, and we can't even rely on *it* being
available everywhere we want it.

- Stability. I'm sure we're all familiar (many through first-hand
experience) with what typically happens when a large code base is
reimplemented: the new implementation fails to capture some subtleties
of the behavior of the old one. Sometimes those are just bugs in the
new implementation. Sometimes they're bugs in the *old* implementa-
tion, but ones that existing software actually depends on. Sometimes
they're undocumented features that somehow leaked out to a customer
or two, or they're quirks that were officially undefined but which
someone decided to rely on.

That means a new implementation needs a lot of testing, and even so
it's going to cause some customers some grief. Again, in the long
run, you'll have a better product for your customers, but in the
short some of them are not going to be happy.

- Resistance. Programmers are an opinionated bunch. While software
development is (let's be honest) a cushy job - I'll certainly take it
over subsistence farming or sweatshop labor - we do put a lot of
ourselves into our work, and it's work that demands both attention to
detail and a measure of creativity. And people who spend a lot of
time using complex tools to create things will have strong opinions
about those tools.

Making a case for switching to OCaml would require not only making
the business case but convincing developers that OCaml is palatable.
But it's unlikely to be to everyone's taste. After all, programmers
generally do manage to self-select the languages they want to work
with, to some extent, particularly in a relatively large and
heterogeneous organization like MF. People who want to write COBOL
will gravitate into positions where they mostly write COBOL; the
Java fans tend to end up in groups that use a lot of Java; and so
forth.

The C and C++ developers at MF are mostly people who have some
affection for C and C++ and the ways those languages are usually
applied. OCaml encourages a rather different problem-solving
approach and uses a very different syntax. I think most of the C and
C++ developers here could learn to like OCaml, because they're smart
folks who will see its possibilities, and because it's interesting,
and because they're professionals who care about their craft and
doing a good job. But there would be resistance which would have to
be overcome gradually, with diplomacy and solid arguments. And
that's good, because you want new ideas vetted by people who know
something about them; but it takes time and it takes social capital,
which like anything else is a finite resource. Pushing a language
change through without convincing its users would be a Pyrrhic
victory at best.

> I believe you may be abandoning the field before a shot is fired. You
> believe you can't win, and there are certainly factors (like the
> "unknownness" of the language) working against you, but if the benefits are
> real, they represent real cost savings and management is duty bound to at
> least hear your case.

Yes, and I think they would; we have a very responsive management
structure here. (In fact, it's one of the major benefits to working
for the "new" MF.) But they'd have to weigh the short-term cost
against the long-term benefit. And I don't think convincing
management is even the harder part of making this sort of radical
change - it's getting agreement (what the business types call "buy-in")
from staff.

> If OCaml can be easily "acquired" by existing
> programmers and if it provides the benefits you believe it does, then why
> not suggest a pilot study?

I've mulled that idea over for a while. It may well be worth doing
when a suitable project comes along. I still don't believe that we'll
ever be able to gather the kind of resources (most particularly time)
to actually convert all, or even most, of our existing C codebase, but
it might be possible to introduce OCaml (or something else) as an
alternative for new development, and gain some of the benefit.

I may try to put together a group to try this out at the next big
developer meeting.

> It seems a pity to me that someone as useful as yourself would not have the
> confidence to try and improve things where you believe they honestly could
> be inproved.

Oh, I've made plenty of suggestions for (what I believe would be)
improvement over the years. No one at MF has ever accused me of not
speaking my mind, that I can recall. :-)

Some have been quite successful, others less so, but again I think
that's appropriate for a large group of smart people who are all
thinking about how to do their jobs. It can actually be quite
encouraging sometimes to have one of my ideas turned down, because
it's generally the result of some quite thoughtful discussion.

> I bet you wouldn't hesitate to rewrite or redesign bad code or
> architecture you came across...:-).

Well, we do have rules about code ownership and so forth, of course,
and tact is important to maintain a healthy work environment - and I
do try to remember that I've been wrong plenty of times. But yes,
when something bothers me I try to see it resolved.

--
Michael Wojcik michael.wojcik@microfocus.com

"Well, we're not getting a girl," said Marilla, as if poisoning wells were
a purely feminine accomplishment and not to be dreaded in the case of a boy.
-- L. M. Montgomery, _Anne of Green Gables_

Peter Lacey

2006-01-25, 6:55 pm

Michael Wojcik wrote:

>
> The history of C is a history of reinvention. Look at all the C APIs
> available for providing GUIs under X11 (a key area for many applica-
> tions which is not covered by the standard language), for example:
> Xlib, Xtk, Xaw, Motif... And yet despite all of those, with their
> often-overlapping functionality, we have many, many X11 C programs
> that implement their own widget libraries. xrn, the newsreader I'm
> using here, is one.
>
>
> Some do, for some tasks. But again I've seen countless lines of C++
> struggling to perform what could be done with far less effort - and
> far fewer bugs - in OCaml. I don't believe richness of already-
> available functionality is really very prominent in commercial
> language selection. It plays a role, but I'm not convinced it's a
> major one in the industry as a whole.
>

You're bringing up a very important issue here. I don't know how much
emphasis there is in programming education on "Standard methods". I
know that any course I've ever taken is all about the language and short
problems. But knowledge of previous art in the field is also of great
usefulness. As you say, the history of "C" is one of re-invention. I'd
guess that the same comment applies to just about any language. The
productivity of any programmer - particularly newbies, who don't have
emotional committments to much yet - would be massively improved by
making him or her aware of what's been done already. This could be (to
a point) language-agnostic because of the need for similar functions in
all applications. Just as a simple example - there must be a "best" (or
several more or less of equal quality) way of implementing a mod-11
check digit routine!

I've always had a litle difficulty with OO programming (leaving aside
DLL's) because of a lack of a precise description of what this or that
one does, along with a searchable index. Could be my problem has been
solved dozens of times!

PL

Peter Lacey

2006-01-25, 6:55 pm

Richard

2006-01-25, 6:55 pm

> Xlib, Xtk, Xaw, Motif...

> Contrast that with languages that have large standard or semi-standard
> libraries, like Java or C++

C++ can use dozens of GUI API: wxWidgets, Qt, GTK, FLTK, FOX, Allegro,
....

Java has AWT, Swing, SWT, wx4j (wxWidgets), BambooKit, Zaval

> That doesn't explain the popularity of, say, C++.

C++ is attractive to C programmers because they can continue writing in
C and using C libraries and existing code and just bolt-on the ++ bits
if there is an advantage.

> Some do, for some tasks. But again I've seen countless lines of C++
> struggling to perform what could be done with far less effort - and
> far fewer bugs - in OCaml.

I don't think that OCaml is in any way unique in that respect. Perl is
renowned for its extreme conciseness, to the point of being cryptic,
Ruby, PHP, ECMAscript (Javascript), Python, can all do stuff in a
handfull of lines that may be pages of C++, Java or Cobol. With Python
it will still be readable.

Oliver Wong

2006-01-25, 6:55 pm

"Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:dr86lm018pk@news1.newsguy.com...
>
> I've seen countless lines of C++
> struggling to perform what could be done with far less effort - and
> far fewer bugs - in OCaml.

I played around with a .NET introspection tool. For any given code
compiled to the .NET platform (regardless of what language it was originally
written in), the tool could decompiled the bytecode into C#, VB.NET or MSIL.

It'd be nice if, in the near future, all programming languages could be
compile to some platform neutral IL, which could be run on any hardware
(with sufficient computational power -- I'm not expecting miracles like
running Windows XP on my wristwatch), and then be decompiled in this
fashion.

Availability of software would no longer be a problem or factor in OS
selection.

The source code within a single file (or "compilational unit") could be
written in a dozen different programming languages, and with a sufficiently
smart IDE, you could just highlight any block of code and translate it to
the language of your choice.

You could write your simple OCaml code, and me, not being an OCaml guy,
would highlight it, right click, and choose "View as Java", say to myself
"Oh... so that's what this does..." and change it back and continue coding
some other part of the system.

- Oliver

Frank Swarbrick

2006-01-25, 9:55 pm

Oliver Wong<owong@castortech.com> 01/25/06 2:34 PM >>>
>"Michael Wojcik" <mwojcik@newsguy.com> wrote in message
>news:dr86lm018pk@news1.newsguy.com...
>
> I played around with a .NET introspection tool. For any given code
>compiled to the .NET platform (regardless of what language it was
originally
>written in), the tool could decompiled the bytecode into C#, VB.NET or
MSIL.
>
> It'd be nice if, in the near future, all programming languages could be

>compile to some platform neutral IL, which could be run on any hardware
>(with sufficient computational power -- I'm not expecting miracles like
>running Windows XP on my wristwatch), and then be decompiled in this
>fashion.
>
> Availability of software would no longer be a problem or factor in OS
>selection.
>
> The source code within a single file (or "compilational unit") could be

>written in a dozen different programming languages, and with a sufficiently

>smart IDE, you could just highlight any block of code and translate it to
>the language of your choice.
>
> You could write your simple OCaml code, and me, not being an OCaml guy,

>would highlight it, right click, and choose "View as Java", say to myself
>"Oh... so that's what this does..." and change it back and continue coding

>some other part of the system.

Now that sounds really

! It would be

even without the "reverse
compile" to a different language. Really, if there was a linkage convention
standard and name-mangling standard it seems to me that a library written in
any language should be accessible from any other language. Of course the
documentation might be hell:

Example C Code:
Example C++ Code:
Example Java Code:
Example COBOL Code:
Example Fortran Code:
Example Python Code:
Example Perl Code:

:-)

To the OCaml guy: What is it specifically that you like about OCaml? Is it
the "functional programming" methodology, the syntax, what? The wikipedia
page http://en.wikipedia.org/wiki/Ocaml says it's popularly used for:

Computer science
- Theorem proving (e.g. Coq, HOL Light, MetaPRL)
- Computer program analysis (CIL, C Code Analyzer)
- Compiler writing (Ocaml compiler, Felix, MTASC)

Natural science
OCaml is also widely used in physics, chemistry, biology and, more recently,
bioinformatics:
- Analysis
- Visualisation

I don't see anything about financial systems and business rules programming
in there, which is COBOL's strength. Do you envision OCaml being used in
the same places as COBOL, or do you just like it for other reasons?

Just wondering. Personally I don't yet understand "functional programming",
but then I haven't made any attempt to learn it. Is it worthwhile in and of
itself, specific languages aside?

Frank

---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA

Defaultuser

2006-01-26, 3:55 am

>>Snipped a long post by "Michael Wojcik" <mwojcik@newsguy.com>

Just wanted to say that was a well considered post. I hope that customers
will learn to appreciate the efforts to which a lot of vendors go to keep
compatible with all the quirks that are created across such diverse
platforms, applications, and styles.

DU

Howard Brazee

2006-01-26, 6:55 pm

On 25 Jan 2006 15:25:57 GMT, mwojcik@newsguy.com (Michael Wojcik)
wrote:

>
>Obviously there are other factors - it's easier to produce a quick-
>and-dirty C compiler than a COBOL one, for example, because the
>language is so much smaller and less ambitious, and so there are far
>fewer features to implement. (Also the parser's a bit simpler,
>though I don't believe that really has much influence on compiler
>writers.) But "everything looks like a nail" does seem to be a major
>influence.

Library languages are easier to develop as well, as you don't have to
make everything perfect and efficient at once. And that is without
making them objects.

Howard Brazee

2006-01-26, 6:55 pm

Nobody would have thought to design CoBOL as two languages - one to
process data, and one to report on it.

But people are buying systems that include utilities such as Crystal
Reports or interfaces to Excel and the like, separating out their
reporting from the other data processing.

One advantage of the new way is that it becomes obvious that some
tools do some tasks better, and that no tool does every task the best.

Oliver Wong

2006-01-26, 6:55 pm

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:43qn0fF1oqu69U1@individual.net...
[quotation got mangled on my side, so I snipped it]
>
> Now that sounds really

! It would be

even without the "reverse
> compile" to a different language. Really, if there was a linkage
> convention
> standard and name-mangling standard it seems to me that a library written
> in
> any language should be accessible from any other language. Of course the
> documentation might be hell:
>
> Example C Code:
> Example C++ Code:
> Example Java Code:
> Example COBOL Code:
> Example Fortran Code:
> Example Python Code:
> Example Perl Code:
>

If you had the "reverse compile to different language" feature, you
could have the example written once, and then reverse compile it.

- Oliver

Richard

2006-01-26, 6:55 pm

> If you had the "reverse compile to different language" feature, you
> could have the example written once, and then reverse compile it.

The problem with that is that you would never wind up with the example
as 'language x program' but as a 'language y program in x syntax'. The
way the code is best arranged for one language depends on features of
that and 'translation' requires 'complete rewrite'. It would require
that the translator identify idioms.

Cobol:
OPEN INPUT file
IF ( File-Status-1 NOT = "0" )
DISPLAY "Not found"
ELSE
PERFORM UNTIL EoF
READ file
AT END SET EoF
NOT AT END
process
END READ
END-PERORM
CLOSE file
END-IF

C:
if ( file = fopen(filename, "r") )
{
while ( ( recpoint = fgets(record, recmax, file) ) != NULL )
{ process; }
fclose(file);
}
else
puts("Not found");

Python:
try:
file = open(filename, "r")
except:
print "file not found"
else:
for record in file:
process
file.close()

Howard Brazee

2006-01-26, 6:55 pm

On 26 Jan 2006 10:01:26 -0800, "Richard" <riplin@Azonic.co.nz> wrote:

>The problem with that is that you would never wind up with the example
>as 'language x program' but as a 'language y program in x syntax'. The
>way the code is best arranged for one language depends on features of
>that and 'translation' requires 'complete rewrite'. It would require
>that the translator identify idioms.

And we can't assume all calls, libraries, and hidden objects work the
same in each environment.

Frank Swarbrick

2006-01-26, 6:55 pm

Richard<riplin@Azonic.co.nz> 01/26/06 11:01 AM >>>
>
>Python:
> try:
> file = open(filename, "r")
> except:
> print "file not found"
> else:
> for record in file:
> process
> file.close()

Hey, that Python stuff is pretty readable. I'm going to have to check that
out.

Frank

Sergey Kashyrin

2006-01-26, 6:55 pm

Oliver,

> It'd be nice if, in the near future, all programming languages could be
> compile to some platform ...and then be decompiled

It's not possible in a good manner.

As a sample you can decompile any Cobol .NET program and you'll see in other
language that a whole Cobol program code is a huge "cobol simulator" because
there are no REDEFINES or GOTO in CLR / other languages.
You'll see that whole your WORKING STORAGE become a single "byte array"
object and there is no single cobol variable name.
And if you try to decompile C# code into Cobol, you will realize that you
don't want and never ever will use Cobol to work with .NET objects.

If you'll try to enhance/change your "some platform" than as soon as you
allow REDEFINES and GOTO and crossed PERFORM-THRU you will not be able to
decompile in all languages or the decompiled program (even back to the same
language) will be very different.

Regards,
Sergey

----- Original Message -----
From: "Oliver Wong" <owong@castortech.com>
Newsgroups: comp.lang.cobol
Sent: Wednesday, January 25, 2006 4:34 PM
Subject: Re: GoTo in Java

> "Michael Wojcik" <mwojcik@newsguy.com> wrote in message
> news:dr86lm018pk@news1.newsguy.com...
>
> I played around with a .NET introspection tool. For any given code
> compiled to the .NET platform (regardless of what language it was
> originally written in), the tool could decompiled the bytecode into C#,
> VB.NET or MSIL.
>
> It'd be nice if, in the near future, all programming languages could be
> compile to some platform neutral IL, which could be run on any hardware
> (with sufficient computational power -- I'm not expecting miracles like
> running Windows XP on my wristwatch), and then be decompiled in this
> fashion.
>
> Availability of software would no longer be a problem or factor in OS
> selection.
>
> The source code within a single file (or "compilational unit") could be
> written in a dozen different programmi