From: "Frédéric Bour" <frederic.bour@lakaban.net>
To: Anthony Tavener <anthony.tavener@gmail.com>
Cc: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] [ANN] OCamp - Reactive programming in the shell
Date: Thu, 02 Apr 2015 14:58:28 +0200 [thread overview]
Message-ID: <551D3CF4.8050101@lakaban.net> (raw)
In-Reply-To: <CAN=ouMS8GxopBUuuwn_GKR62fdL7H9o+S3LBPcA_NunX85YKrQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5250 bytes --]
I am trying to specialize in /elaborate jokes/ :).
The idea and implementation started as a joke… But with some hindsight,
this might not be completely inappropriate.
In any case the current implementation is really just a proof of
concept, not to be trusted at all.
On 02/04/2015 14:19, Anthony Tavener wrote:
> Hah! You were serious? I thought with commands like hipp and stir, and
> your legal review notice at the end, that this was an April Fool's
> joke. :)
>
> On Thu, Apr 2, 2015 at 12:38 PM, Frédéric Bour
> <frederic.bour@lakaban.net <mailto:frederic.bour@lakaban.net>> wrote:
>
> Code is finally available at:
> https://github.com/def-lkb/ocamp
>
> Sorry for the little delay!
>
>
> On 01/04/2015 22:32, Frédéric Bour wrote:
>
> OCamp extends unix shells with constructions to express
> memoization, sharing of computations and reactive programming.
>
> # Subcommands
>
> ## fire
>
> Just wrap a unix command with "ocamp fire" to enable the
> extension:
> $ ocamp fire bash
>
> This will spawn a new bash session where the following
> subcommands are enabled.
>
> ## hipp
>
> $ ocamp hipp <command>
>
> Will memoize the output and exit status of <command>.
> Later calls to the same <command> won't lead to actual
> execution, but just to a duplication of its previous output.
> Concurrent calls to <command> will just share the same
> process, the beginning of the output being replayed to later
> callers.
>
> The identity of a command is defined by its arguments and
> working directory.
>
> ## stir
>
> $ ocamp stir <command>
>
> Indicate potential changes in the output if <command> was rerun.
> Later calls to `hipp` will recompute <command> as if it was
> not yet memoized.
>
> ## (un)follow
>
> $ ocamp follow <command>
>
> First, <command> is memoized if it was not the case yet.
> Then changes to dependencies of <command> will trigger a
> reevaluation.
> Use `stir` to notify a change.
>
> (to follow is an hipp/stir reactivity).
>
> ## pull
>
> $ ocamp pull <command>
>
> Closely related to `hipp`, but instead of marking dependency
> on the output of <command>, the dependency applies to the
> "effects" of <command>.
>
> Thus, if `stir` is used:
> - all pullers will be reevaluated.
> - hippers will be reevaluated only if the output is different.
>
> ## Summary
>
> $ ocamp fire <command> - setup a new session alive until
> <command> exits
> pull <command> - mark dependency on effects of <command>
> hipp <command> - mark dependency on output of <command>
> stir <command> - notify that <command> might have
> been updated
> follow <command> - eval <command>, and reactively
> recompute it
> whenever one of its dependencies
> change.
> unfollow <command> - stop recomputing <command> when
> dependencies
> change
>
> hipp and pull provide memoization.
> stir and follow bring a flavor of reactive programming.
>
> # Examples
>
> ## Fibonacci
>
> $ cat fib.sh
> #!/bin/sh
> ARG="$1"
> if [ "$ARG" -le 1 ]; then
> echo "$ARG"
> else
> A=`ocamp hipp ./fib.sh $((ARG-1))`
> B=`ocamp hipp ./fib.sh $((ARG-2))`
> echo $((A+B))
> fi
>
> $ time ocamp fire ./fib.sh 50
> 12586269025
> real 0m0.391s
> user 0m0.153s
> sys 0m0.060s
>
> ## Build-system
>
> `ocamp` provides simple primitives to construct and manage a
> dependency graph.
>
> This might be a saner foundation to base a build-system on
> than make(1):
> - the command focus on one specific problem
> - no dsl is involved; rules can be plain unix commands,
> including a shell, rather than a make-flavored simulation of shell
> - nothing is provided for resolving goals; indeed this is
> better left to tools specifically built for goal-search.
>
> A quick'n'dirty script building ocamp itself is provided as an
> example.
>
> # Future
>
> The current release is a proof-of-concept and should be
> considered alpha quality.
> The two features planned next are a way to make the graph
> persistent (all data is kept in memory atm) and an interface
> to debug and/or observe graph construction.
>
> Note: code is undergoing legal review and should be available
> soon \o/
>
>
>
> --
> Caml-list mailing list. Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>
[-- Attachment #2: Type: text/html, Size: 9219 bytes --]
prev parent reply other threads:[~2015-04-02 13:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-01 20:32 Frédéric Bour
2015-04-02 10:38 ` Frédéric Bour
2015-04-02 12:19 ` Anthony Tavener
2015-04-02 12:58 ` Frédéric Bour [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=551D3CF4.8050101@lakaban.net \
--to=frederic.bour@lakaban.net \
--cc=anthony.tavener@gmail.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox