Re: [Felix-language] [felix] Active programming revolution

[Ryan G. <ry...@gm...>]

So...

...


isn't this basically stack-oriented programming without a stack?

Related project of interest:

http://code.google.com/p/anic

On June 2, 2015 7:10:08 PM CDT, john skaller <sk...@us...> wrote:
>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
>sk...@us...
>http://felix-lang.org
>
>
>
>-- 
>You received this message because you are subscribed to the Google
>Groups "Felix Language" group.
>To unsubscribe from this group and stop receiving emails from it, send
>an email to fel...@go....
>To post to this group, send email to fel...@go....
>Visit this group at http://groups.google.com/group/felix-language.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.