Arrows are essentially a formalization of box-and-wire paradigms. http://en.wikibooks.org/wiki/Haskell/Understanding_arrows
Arrows represent a rigid structure for dataflow, but are just expressive enough for non-linear composition of subprograms (i.e. parallel pipelines that branch and merge). One might consider this a bitter-sweet spot. For some people, it's too rigid. Fortunately, we can add just a little more flexibility: 1) runtime-configurable boxes/arrows, that might even take another box/arrow as input 2) metaprogramming - components execute in earlier stage than the runtime arrows I support both, but metaprogramming is my preferred approach to flexibility. Box-and-wire paradigms, even arrows, usually run into a problem where they get unwieldy for a single human to construct - too much wiring, too much tweaking, too much temptation to bypass the model (e.g. using a database or tuple space) to integrate different subprograms because we don't want wires all over the place. Metaprogramming overcomes those limitations, and enables structured approaches to deep entanglement where we need them. :) Best, Dave On Tue, Sep 3, 2013 at 6:33 PM, Casey Ransberger <[email protected]>wrote: > Sorry, I've missed a beat somewhere. "Arrowized?" What's this bit with > arrows? > > I saw the term arrow earlier and I think I've assumed that it was some > slang for the FRP thing (if you think about it, that makes some sense.) But > starting with intuitive assumptions is usually a bad plan, so I'd love some > clarification if possible. > > > On Sep 3, 2013, at 5:30 PM, David Barbour <[email protected]> wrote: > > Factor would be another decent example of a concatenative language. > > But I think arrowized programming models would work better. They aren't > limited to a stack, and instead can compute rich types that can be > evaluated as documents or diagrams. Further, they're really easy to model > in a concatenative language. Further, subprograms can interact through the > arrow's model - e.g. sharing data or constraints - thus operating like > agents in a multi-agent system; we could feasibly model 'chromosomes' in > terms of different agents. > > I've recently (mid August) started developing a language that has these > properties: arrowized, strongly typed, concatenative, reactive. I'm already > using Prolog to find functions to help me bootstrap (it seems bootstrap > functions are not always the most intuitive :). I look forward to trying > some genetic programming, once I'm further along. > > Best, > > Dave > > > On Tue, Sep 3, 2013 at 4:45 PM, Brian Rice <[email protected]> wrote: > >> With Forth, you are probably reaching for the definition of a >> concatenative language like Joy. >> >> APL, J, K, etc. would also qualify. >> >> >> On Tue, Sep 3, 2013 at 4:43 PM, Casey Ransberger < >> [email protected]> wrote: >> >>> I've heavily abridged your message David; sorry if I've dropped >>> important context. My words below... >>> >>> On Sep 3, 2013, at 3:04 PM, David Barbour <[email protected]> wrote: >>> >>> > Even better if the languages are good for exploration by genetic >>> programming - i.e. easily sliced, spliced, rearranged, mutated. >>> >>> I've only seen this done with two languages. Certainly it's possible in >>> any language with the right "semantic chops" but so far it seems like we're >>> looking at Lisp (et al) and FORTH. >>> >>> My observation has been that the main quality that yields (ease of >>> recombination? I don't even know what it is for sure) is "syntaxlessness." >>> >>> I'd love to know about other languages and qualities of languages that >>> are conducive to this sort of thing, especially if anyone has seen >>> interesting work done with one of the logic languages. >>> _______________________________________________ >>> fonc mailing list >>> [email protected] >>> http://vpri.org/mailman/listinfo/fonc >>> >> >> >> >> -- >> -Brian T. Rice >> >> _______________________________________________ >> fonc mailing list >> [email protected] >> http://vpri.org/mailman/listinfo/fonc >> >> > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
