# Distributed Joy

## John Cowan — 2001-05-02 01:32:52

    I got to thinking tonight about distributed Joy.  Yet another beauty of

    concatenative programming is that sandboxing is almost automatic: all we have

    to do is to control the behavior of file words.

    The external view I'm thinking about is a combinator "remote-i", which accepts

    a quotation and a string that refers to some remote Joy system.  It

    connects to the remote system (details to be worked out), transfers the

    *entire contents of the stack* to that system over the network including the

    quotation, and causes it to be executed as if by "i".  The entire contents

    of the stack are then transferred back.

    The remote system runs in a mode where certain words are illegal:

    specifically "fopen", "stdin", "stdout", "stderr", "fremove", "frename".

    It also treats file stream objects specially: rather than referring to

    file streams on the remote system, they cause network interactions

    whose effect is to read or write from the corresponding file stream

    objects on the local system.

    Another similar combinator would be "remote-spawn", which is essentially

    equivalent except that the stack is not transferred back and file streams

    are not supported at all.  This provides for non-synchronous ("background")

    execution.

    --

    John Cowan                                   cowan@...

    One art/there is/no less/no more/All things/to do/with sparks/galore

    	--Douglas Hofstadter

## Manfred von Thun — 2001-05-02 06:41:07

    On Tue, 1 May 2001, John Cowan wrote:

     > I got to thinking tonight about distributed Joy.  Yet another beauty of

    > concatenative programming is that sandboxing is almost automatic: all we have

    > to do is to control the behavior of file words.

     All purely functional languages have this property: the order of

    evaluation of an expression does not matter for the final result

    - and hence some subexpressions can be evaluated concurrently.

    Example:

           (2 * 3)  +  (4 * 4)              original

              6           16                concurrently (remotely) evaluated

                    22                      after both subvalues are avail.

     >

    > The external view I'm thinking about is a combinator "remote-i", which accepts

    > a quotation and a string that refers to some remote Joy system.  It

    > connects to the remote system (details to be worked out), transfers the

    > *entire contents of the stack* to that system over the network including the

    > quotation, and causes it to be executed as if by "i".  The entire contents

    > of the stack are then transferred back.

     For uniformity and simplicity it is probably best if _only_ a program

    is transferred. If the whole stack is also required, do this:

        stack [unstack remote-program] cons remote-i

    If only part of the stack is required by remote-program, cons just

    the required values into the quotation (some reversal may be needed)

    before remote-i.

     > The remote system runs in a mode where certain words are illegal:

    > specifically "fopen", "stdin", "stdout", "stderr", "fremove", "frename".

     Also "get" and "put" - especially if several remotes are done

    concurrently. This will be true of any functional language.

     > It also treats file stream objects specially: rather than referring to

    > file streams on the remote system, they cause network interactions

    > whose effect is to read or write from the corresponding file stream

    > objects on the local system.

    >

    > Another similar combinator would be "remote-spawn", which is essentially

    > equivalent except that the stack is not transferred back and file streams

    > are not supported at all.  This provides for non-synchronous ("background")

    > execution.

     My view would be to look at the mature functional languages, and

    see whether they do this sort of thing, and when in their history

    they started it. My suspicion is that Joy is too young to even

    consider it at this stage. But I may be wrong. Any views?

    For me an important consideration would be whether and to what

    extent the concatenative semantics suffers.

      - Manfred

## John Cowan — 2001-05-02 13:25:40

    Manfred von Thun wrote:

     > For uniformity and simplicity it is probably best if _only_ a program

    > is transferred. If the whole stack is also required, do this:

    >     stack [unstack remote-program] cons remote-i

    > If only part of the stack is required by remote-program, cons just

    > the required values into the quotation (some reversal may be needed)

    > before remote-i.

     That works provided the stack contains only value objects.  But it

    will not work if the stack contains nude words, nor if it

    contains file streams, for there are no syntactic constructors

    for these things.

     >> The remote system runs in a mode where certain words are illegal:

    >> specifically "fopen", "stdin", "stdout", "stderr", "fremove", "frename".

    >

    > Also "get" and "put" - especially if several remotes are done

    > concurrently. This will be true of any functional language.

     Not illegal, just processed differently.  The remote Joy executes

    get by passing it back to the local Joy, which executes it normally

    and returns the result to the remote system.  Likewise for put, ftell,

    fseek, fputch, fput, fwrite, fread, fgets, fgetch, fflush, ferror,

    feof, fclose.

    (The coolness of this is that no specialized remote-access protocol is

    needed: the local system passes some Joy to the remote system, which

    executes it.  When the remote system needs to do I/O, it concocts some

    Joy and passes it to the local system, which executes it and passes

    back the result.  Finally, when the remote system terminates, its stack

    is sent back as Joy code to the local system, which then executes it

    and carries on.)

    This is what I meant by:

     >> It also treats file stream objects specially: rather than referring to

    >> file streams on the remote system, they cause network interactions

    >> whose effect is to read or write from the corresponding file stream

    >> objects on the local system.

     What makes this so effective is that it is the local program that

    must authorize changes to local (file stream) state.  A program

    executing remotely cannot open any resources on the remote system

    other than computational cycles, nor can it even open any *novel*

    resources on the originating system.  It can only access the

    resources that the local system has already established capabilities to.

    This can all be piggybacked on a general facility, which I will build

    first, for fopen-ing network streams.

     > My view would be to look at the mature functional languages, and

    > see whether they do this sort of thing, and when in their history

    > they started it. My suspicion is that Joy is too young to even

    > consider it at this stage. But I may be wrong. Any views?

     I think that this feature *should* be included in Joy early in

    its evolution.  It is simply much easier to distribute snippets

    of Joy code than to distribute functional language closures.

    This is due not only to the concatenative nature, but also to the

    fact that there is no mutable state except the file system.

     > For me an important consideration would be whether and to what

    > extent the concatenative semantics suffers.

     On the contrary, it is preserved perfectly, at least in the

    synchronous case that I am considering.  The semantics of

    remote-i is precisely that of i, so it is theoretically

    completely tractable.

    --

    There is / one art             || John Cowan <jcowan@...>

    no more / no less              || http://www.reutershealth.com

    to do / all things             || http://www.ccil.org/~cowan

    with art- / lessness           \\ -- Piet Hein