I need a message-goto object language

[Paul Dufresne]

I intended this as a one message to reply to all the answers I have
receive,
but somehow it turned out
more to look as something like "thanks for all the info, just let me
some
time to look at it". Here it is
anyway:

> Perhaps my confusion lies in what you call the "true programing language".

I just wanted to means real.

>  (in c/c++, the languages that I am
> most familier with, you can tell the compiler that a function may never
> return by declaring it volatile, I think).

I shooed look at this.

> The general vibe that I have allways picked up on is that functional
> programing is superior.  Then again, maybe It would be usefull for
> something, and I dont know what I'm talking about.

Yes,  but does functional programming have methods and/or notations,
something like UML for OOP?


> I will put in a plug here for you to consider a
> specification language instead of a programming
> language as this will allow automated generation of
> dataflows, structure charts, and executables from
> the writing of a single set of specifications.
> Thus the only "people translation" that takes place
> is that from user requirements to specifications.
>

I would be grateful to you to post a link on this.

> As a historical note Kenneth Iverson's book "A
> Programming Language" is slightly misnamed as he
> proposed its use as a specification language to
> replace flowcharting.  I would recommend highly
> your reading at least Chapter 1 to see how to
> visually represent functions and their
> interconnection.  I say visually because you can
> "see" the difference between a well-structured
> program and one of spaghetti "go-to" code.
>

I'll try to find this, it looks interesting.


> One word: Continuations
>

Yes, I think I heard about it in Scheme, but it looked something weird
back
then.
I'll take a deeper look on this, but I think you're right, because I do
assume that the state of each box is remembered between each 'calls',
thanks!


> 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
>

Thanks, I knew about it, and I was thinking to use this as a more
traditional
way of doing it.


> 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
>
Ok, I'll take a look at those links, thanks!

I now think I remember something similar in C--, to help implement
tail recursion. I need to go see how
the C-- project is evolving.

Anyway, since it is a small project I am working on, I will remake the
analysis in a more traditional way,
but somehow my diagrams was something I did not really knew existed, and
I
wanted to share with others
to see if this was not an interesting idea to use.  So after all it
doesn't
seems a really new idea, but I will
have learn from your answers. Thanks!