Lambda the Ultimate

...the system basically does have to be a keyboard typing input to be quick and productive. I guess I should explain myself better.

Normally you would write something in a functional text-based language like so:

int X(int I) {
int B(int J) = 2-3*J+4;
} = I*B(I) + Sum(1..5) + B(I)/2;

Where the function B (that returns an integer type) is a closure inside the function X.

This function X, has an irregular dependancy, meaning that if both X and B were parsed into a tree, the tree structure would be irregular, becaues X refers to B twice. B would branch off to two places of the tree of X. In imperative programming, one would make use of a temporary variable to store the result of B(I) to eliminate redundancy:

int X(int I) {
int B = 2-3*I+4;
result = I*B + Sum(1,5) + B/2;
}

For imperative languages, this creation of a variable is syntactic overhead that shouldn't be needed using the functional approach.

Now here is the idea: A dataflow language can represent the tree structure itself, which is not disconnected into parts. The structure of a dataflow language is continuous, eliminating the need to name a variable/closure and reference it. From the point of view of a dataflow language, not only is variables a sin, but so are (at least) these kinds of closures. This is what I am trying to achieve--to eliminate even more verbosity, while allowing one to program irregular dependancies in a continuous, rather than a broken up fashion, and the same will be true of flow of execution, which will not be restricted to a one-way, sequential order, but can be irregular (like a flow chart). This is where the discrepancy comes in between just typing in code, and the visualization.

This could go in so many directions I'm not sure what kind of advice to give you. First, you might want to look at Jonathan Edwards's Subtextual language, which does away with names all together in a language with a structured programming editor. In any language, there is a balancing act between abstraction (hiding details) and directness (code resembling program execution), and you often have to tradeoff one for the other. Subtextual provides a way around this.

You might want to also look at Simony's intentional programming project, where imperative C# code can be visualized and edited in different ways (e.g., as a flow chart or spread sheet).

In my own SuperGlue language, which is basically a textual data-flow language, I've found closures (and functions!) to not be very usable and have instead replaced them with declarative (quantification and connection-based abstractions). Data-flow programming is very different from imperative or even functional programming and benefits from different core abstractions. The nice thing about SuperGlue is that a rule parameterized by universally quantified variables placed anywhere in the code can affect the execution of the entire program.

It was not until I started reading Iverson's papers that I realized that he often used phrases of the form

X•X←Y

which these days we'd tend to write in the Landin tradition as

X•X where X = Y

Now, using naming to indicate sharing in the graph structure doesn't immediately solve your problem, even if no actual closures or temporaries need be generated. However, J hooks and forks were a later attempt to capture common branching patterns in code graphs, and express them without needing to invent names. (it is unclear to me how successful J is in practice. I think that Whitney has said (as implemented in K) that he finds composition to be far more useful than the J sharing patterns)

A halfway point on the spectrum from pointing (as in Subtext?) to naming might be to have a common set of pronouns. English speakers have former and latter, even this, that, and those. American Sign Language apparently has a pronoun structure by which a noun phrase is signed in a particular area, and subsequently referred to by location. To some degree, APL had this as well, for the standard α and ω (left and right arguments to an operator) could be duplicated several times in a definition.

As an example, I believe the APL definition of counting sort would be

(+/ωο.=α)/α

in which the lexical order for the sort is duplicated, but all the names are forced by the conventions of the language.