Hi all.

Back in my college days, I used to program my Sharp PC-1401 using its built-in BASIC language.

As an aid to that, I learned to put down on the paper a flow-chart with all the boxes (inputs, outputs, decisions, storage etc.).

Switching the matter to RPN logic and RPL programming language, I was wondering if the structure and logic of a flow-chart

would remain the same or if a new "layout" should apply - I mean more functional

and straighforward to be input as a program.

Perhaps a dumb question, but a clarification would be welcome.

Thank you for your feedbacks.

Best regards.

Giancarlo

Edited: 16 June 2006, 3:04 a.m. after one or more responses were posted

Flow charts would work, but with RPL's emphasis on GOTO-less structured programming, you might be better off using Nassi-Schneiderman diagrams. Googling will turn up lots of links, but http://www.smartdraw.com/tutorials/software-nassi/nassi.htm has some nice illustrations that get the point across, while http://www.cbu.edu/~lschmitt/I351/Nassi%20Schneiderman.htm is a longer article.

The idea is to represent logic graphically using just the classic straight-through-execution, if. . . then . . . else and while structures. This should map quite well to the flow control structures available in RPL, although I've never tried it.

Best,

--- Les Bell

[http://www.lesbell.com.au]

So long as one uses local and global variables for parameters that are passed to the branch/loop commands, then the flow charts should be exactly the same. However, since RPL also has a stack from which the branch/loop commands can take input, the flow charts would have to be slightly different.

That is, the "X=Y" statement within, say, a "square" (flow chart element) would not make sense if X and Y were pulled from the stack. If no stack history is kept, who knows what X and Y really are...

Quote:

---

That is, the "X=Y" statement within, say, a "square" (flow chart element) would not make sense if X and Y were pulled from the stack. If no stack history is kept, who knows what X and Y really are...

---

There's no reason why Giancarlo should have to use conventional algebraic assignment notation in either a flowchart or Nassi-Schneiderman diagram, Han. It's all pseudo-code at that point, and he can use RPL code directly, or whatever makes sense to him. Of course, it's not that difficult to hand-compile algebraic logic into RPN/RPL, although one might miss out on some neat optimizations while doing that.

Best,

--- Les Bell

[http://www.lesbell.com.au]

Is there really any point in flowcharting RPL? I have not learned RPL, but it looks similar to Forth; and appropriate factoring and good placement of especially the structure words in the Forth source code make it quite clear what's happening. That's not to say all Forth code is clear. I've seen loads of disastrous examples, and Forth has sometimes been called a write-only language; but that's the programmer's fault! Forth is said to make good programmers better and bad ones worse. The bad ones need to lay out their code better, not spend their time flowcharting.

On the other hand, unstructured calculator languages like the HP-41's might sometimes benefit from flowcharting. What I've been doing for HP-41 programs however is to type them into a text editor on a hi-res monitor with sometimes several instructions on a line, and writing plenty of comments in. It doesn't make it a structured language, but it does make it more comprehensible.

Quote:

---

Is there really any point in flowcharting RPL?

---

Uh . . . you don't flowchart the RPL - you flowchart (or diagram) your algorithm as you develop it. Flowcharting is an aid for more visual thinkers as they design a program, not an aid for coders after the fact.

Then, from the diagram, comes the code.

Best,

--- Les Bell

[http://www.lesbell.com.au]

Oops, I left out the word "for"-- flowcharting for RPL, as if to draw a schematic before building a circuit, since the circuit's visual appearance tells very little about what it does. In contrast, a "well-built" piece of source code in a structured language shows rather clearly what it does. It is its own diagram. (That's not to excuse the total omission of comments though, since they are part of the complement.)

I never learned Forth or any RPL-like language in the past, so flowcharting has always been
to me like a tool to "translate" thoughts into a first draft of algorithm and then into code.
Les, thank you for the tip about Nassi-Schneidermann charts - I was completely unaware
of them, but I'll go through the articles you suggested during my next flight
(on Monday), trying to use them to sketch some simple code.
Thank to all the contributions about this subject - very interesting and
thorough as usual!
Cheers.
Giancarlo

Quote:

---

There's no reason why Giancarlo should have to use conventional algebraic assignment notation in either a flowchart or Nassi-Schneiderman diagram, Han. It's all pseudo-code at that point, and he can use RPL code directly, or whatever makes sense to him. Of course, it's not that difficult to hand-compile algebraic logic into RPN/RPL, although one might miss out on some neat optimizations while doing that.

Best,
--- Les Bell

[http://www.lesbell.com.au]

---

You are quite right, Les. I now realize that a flowchart should reflect the flow of the algorithm and not the actual code or even implementation.