CALL RETURN

16 views
Skip to first unread message

Paul Tarvydas

unread,
Jul 6, 2021, 3:24:31 PM7/6/21
to Flow Based Programming

CALL/RETURN

To emphasize the vast chasm in belief structures, imagine CALL/RETURN.

CALL/RETURN restricts the programming domain in several ways:

1. CALL/RETURN performs scheduling (the caller is suspended, the callee runs immediately).
2. Parameters are delivered in a synchronous block - all at the same time.
3. Return Value(s) are delivered in a synchronous block - all at the same time.
4. The Callee springs to life then dies.
5. We (the Royal We) add a kludge, called “Exceptions” to the syntax of CALL/RETURN to compensate for the shortcomings of the kludge that we call CALL/RETURN.
6. CALL/RETURN is implemented - cast in hardware - using a global variable.

We (the Royal We) use an artificial kludge to take control back in situation #1. Operating systems like to think that they control scheduling, but CALL/RETURN violates that notion. Operating systems use “preemption” to wrench scheduling control away from the caller. Preemption comes with its own baggage cart of accidental complexity.

Asynch Components (which includes FBP) drive a stake through the heart of CALL/RETURN. Once you know how to program asynchronously, you can’t unknow how. Until you know this, though, you are only looking at shadows on the wall (often called “thread libraries”, “lazy evaluation”, etc.) and you couch everything in the language of not-knowing.

Note that Relational Programming and FP are - slowly - learning how to expunge CALL/RETURN from notations.

Note that internet programming and distributed programming (e.g. blockchain, p2p) are - slowly - exposing the fallacy of CALL/RETURN.

Thinking-in-async is very, very, very different from thinking-in-sync. Async solutions are very, very, very different from sync solutions for the exact same problem.

pt


Paul Morrison

unread,
Jul 6, 2021, 7:07:59 PM7/6/21
to flow-based-...@googlegroups.com
From my book, referring to the 1989 article on Linda by Gelernter and Carriero: " our experience with FBP tells us that the subroutine call is not the best foundation on which to build business applications. A “call” can in fact be simulated very nicely by issuing an FBP “send” followed by a “receive”. This will have the effect of suspending the requester on the “receive” until the downstream process returns an answer, just as a “call” suspends the caller. Gelernter and Carriero make the same point and go still further in the above-mentioned article:

“In our experience, processes in a parallel program usually don’t care what happens to their data, and when they don’t, it is more efficient and conceptually more apt [my italics] to use an asynchronous operation like Linda’s “out” [FBP's "send"] than a synchronous procedure call.... It’s trivial, in Linda, [or FBP] to implement a synchronous remote-procedure-call-like operation in terms of “out” and “in” [FBP “send” and “receive”]. There is no reason we know of, however, to base an entire parallel language on this one easily programmed but not crucially important special case.”

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/flow-based-programming/6fa9bc4b-f183-419b-9d6a-b1830094d3f9n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages