I need a message-goto object language

[Jecel Assumpcao Jr]

Paul Dufresne wrote:
> I use to be a bad programmer that directly go and program on the
> computer rather than thinking on paper
> before going on the computer.

If it worked, then you weren't a bad programmer. If doing this sometimes
got you into trouble, then you were :-)

> But this time, I decided to spend some
> times on paper. I usually avoid flowcharts prefering to use pseudo-code.

They are equivalent, so you whatever you are more confortable with.

> Flowcharts ('ordinogramme' in french) often give some nice paper results
> that is not so easy to
> transform in while and for without using any goto.

The very old style of flowcharts has this problems (as they were
designed to be used with Fortran this is no surprise). You can get
better results by using a Nassi-Shneiderman chart instead:

  http://www.olympic.ctc.edu/class/akkirkpa/cs165l01.html

Since they are so new (1973 ;-) not everyone has heard of it yet. That
page doesn't have any complete examples, unfortunately. If you design
using this kind of notation, you can very easily generate structured
code from it (I did this back when I programmed in Algol and Pascal).

> The obvious way to
> program this kind of flowchart is to
> just not doing any while, repeat or for and just use ifs and gotos. But
> this time, I began writing some
> kind of flowchart. Not exactly traditional one. I just make some kind of
> data-flow diagram. Each box
> have some inputs arrows (in my mind incoming messages), and output
> arrows (outgoing messages).

If this is the style of system you prefer to design, it is a nice
choice. Depending on how you defined the synchronization of the input
messages this same diagram can represent a data flow system or a CSP
system (communicating sequential processes).

> In my mind, arrows was the data-flow of the program, so data-flow can
> enter by any arrows, and must
> get out by one outgoing arrows. Inside a box, there are others boxes.
> Well, on paper it does not look too
> much spaghetti, like we use to call this kind of goto-message
> programming, because the program is
> structured in a systemic way (boxs in boxs).

Exactly - as long as the boxes are properly nested (no overlaps) you
have a strictly structured system.

> But now it seems hard to program in a true programming language, because
> normally, calling a method
> suppose that the data-flow will come back, and I did not make this
> assertion in doing my flowcharts.
> To allow a return value, I just create an other ingoing arrow at my box,
> and the box I send a message can
> send a value to the previously mentionned ingoing arrow, but it is not
> mandatory like in all programming
> languages I seems to know. How am I suppose to transform my flowchart to
> program it. Or maybe I would
> have to create a new object-oriented language that do message-goto
> rather than message-calling.n :-)

Data flow charts are easily converted into a subset of functional
languages called "single assignment languages". Or you might want to
execute the graphical representation directly using such systems as
ProGraph and LabView.

  http://www-csd.ijs.si/silc/pdcp.html
  http://www.cs.berkeley.edu/~maratb/cs263/paper/node14.html
  http://www.ni.com/labview/what.htm

If you are using CSP instead (explicitly receiving the messages) then
you can easily implement your system in Occam.

  http://www.dcs.qmw.ac.uk/SEL-HPC/Articles/GeneratedHtml/hpc.occam.html

Since you mentioned object-oriented languages, you might find their
cousins interesting: Actor languages. In most of these languages you
have to explicitly send another actor a "return envelope" if you are
expecting an answer back from a message. The difference is that you can
create new arrows at runtime, which is hard to model with a paper
diagram.

  http://www.dekorte.com/Actors/Chart.html

> I hope I made myself clear enough to be understood.

And I hope this helps.

-- Jecel