Re: [stack] A Joy VM in OCaml

On Wed, Sep 02, 2009 at 12:22:33AM +0300, chris glur wrote:
>     
> 
>    > I've been pondering for a while about whether this is useful
>    > to actually turn into an application: to build a unix shell
>    > that _is_ a concatenative language. It's a lot of work to get
>    > right though.
>    >
>    > However, starting with scsh this might not be so far-fetched..
>    I'd like to see a collaborative project in that direction;
>    which was very transparent.
>    I.e. doesn't just publish the final products hand-book, but
>    rather exposes all steps of the design process.
> 
>    OTOH perhaps such "democratic committee" projects aren't feasible.

I believe good results require a sufficiently annoying `itch' locally
applied to a single implementor / designer.

Committees are probably only useful if there are too many people with the
same itch but different ways of scratching, or if a sufficiently
annoying itch doesn't emerge spontaneously.

Considering joy vs. shell programming, I do have a couple of ideas though,
while I think it's far from trivial to do it right.

 - If you can figure out how to map programs, program arguments, and
   pipes to clearly defined Joy function and data objects, and figure
   out how to mesh the different name spaces the job seems half way done.
   The rest is the long tail of infinite refinement and bug hunting.

   I.e. the shell language could be a combination of

     - Joy combinators

     - Programs (can they be joy combinators? how to mix function
       and file system namespaces?)

     - Command lines of most sufficiently complex programs behave as 
       `mini-DSLs'.  Can they be mapped to combinators, or should they
       be abstract data?  Can you brush this away into a wrapper
       by treating providing some kind of compiler/interpreter for
       each sufficiently complex external app (a good example would
       be mplayer/mencoder).

 - It might be a playing field where the original highly reflective 
   intensional Joy approach is workable.  In all other practicaly
   applications of concatenative languages I see, extensional approach
   seems to be better from both modularity and efficiency viewpoints
   (i.e. where you want play with static code properties).