There is about to be a major paradigm shift in the world of
programming: Active Programming.

I have spent over 15 years developing a strong enough core to
actually implement what the original commercial job required,
and it leads to complete paradigm shift: Active Programming.

Here's what happens. in the old world we have imperative
stateful programming languages with expressions thrown in.
Control flow was king. The pairing of data flow and control
flow was broken by C and similar languages with the notion
of functions using the machine stack (data and control passed
together on the stack).

On the other side, functional programming touted declarative
specifications based on mathematics, and because of the mathematical
basis this style is ostensibly easier to analyse because of the wealth
of mathematical skills and knowledge available. But purely functional
languages just don't cut it in practice: performance is one issue but
the simple reality is recursion is too hard to understand and doesn't
match reality.

Active programming MERGES stateful imperative programming
and functional programming into a single paradigm. The paradigm
is fully declarative and so amenable to analysis. 

At present I am just doing the basics. The simplest form is a pipeline:

  #((1,2,3,4,5).iterator |-> (fun (x:int) => x + 1) |-> (fun (x:int) => x * x) 
|-> println[int]);

In this form we have sources, sinks, and transducers. A source combined with
a transducer is another source. A transducer combined with a sink is another
sink. The pipeline operator is associative.

A source is basically a lazy list or stream of values. A sink is basically
a continuation. You can view the pipeline by splitting it into any three parts
at ANY connection:

        SOURCE |-> TRANSDUCER |-> SINK
        generator |-> function |-> continuation

The model is beautifully symmetrical. A sink is the categorical dual of a 
source.

The objects here are objects of a category, and the pipe operators are the
arrows. So in fact we have built a mechanical model of a category.

Each of the components are called "chips" and the pipes are called "wires".

The chips and wires model can be much more general and is based on
the picture of a thing called a multigraph. A normal graph has vertices
which are just connection points, and edges which connect at vertices.

A multigraph is the quite different. Here the "wires" or "edges" are the
connections and the "chips" or "vertices" are the important things.
Chips can have multiple inputs and outputs and they do things.

There are many ways to connect chips. The pipeline is just simplest.
We shall see pipelines subsume all functional programming, when
enhanced with recursion.

A chip is an ACTIVE device. They are each an fthread (fibre).
Each chip is a MASTER. There are no slave subroutines.
This is the primary fault of all functional programming.

There's nothing wrong with slaves .. the problem is when you ONLY have
master/slave relations instead of also having peer-peer relations.
In the chips and wires model, all chips are peers.

Note that in a pipeline CONTROL FLOW IS NOT DETERMINATE.
Data flow is determinate. It flows left to right along the pipes.
But there is no requirement data be written onto a pipe first,
then the data be read. Instead, data could be requested,
and then supplied. Indeed, this is what schannels do.
They're synchronisation points: neither reader nor writer
may proceed until they exchange the data, but it isn't determined
who comes or goes first. As long as they synchronise.

Control flow is not arbitrary. There are constraints. But the paradigm
is declarative so the details are hidden.

The implementation details are in

        src/package/spipes.fdoc

There's a lot more to do. One of the most astounding facts is this:
Consider a circuit board populated with chips. Got the picture?

Ok, So PULL SOME CHIPS OUT.

What have you got????


POLYMORPHISM.

Only, the "type variables" are now "chip variables", that is,
empty sockets, and we need to plug in chips with a particular
signature and behaviour. [Chip variables are basically the
same idea as Ocaml module signatures only the active
programming concept is much better than modules/functors
because a chip is an ACTIVE device, not merely a collection
of slave functions]

--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org




------------------------------------------------------------------------------
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to