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
On Tue, 1 May 2001, John Cowan wrote:
> I got to thinking tonight about distributed Joy. Yet another beauty ofAll purely functional languages have this property: the order of
> concatenative programming is that sandboxing is almost automatic: all we have
> to do is to control the behavior of file words.
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.
>For uniformity and simplicity it is probably best if _only_ a program
> 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.
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:Also "get" and "put" - especially if several remotes are done
> specifically "fopen", "stdin", "stdout", "stderr", "fremove", "frename".
concurrently. This will be true of any functional language.
> It also treats file stream objects specially: rather than referring toMy view would be to look at the mature functional languages, and
> 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.
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
Manfred von Thun wrote:
> For uniformity and simplicity it is probably best if _only_ a programThat works provided the stack contains only value objects. But it
> 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.
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:Not illegal, just processed differently. The remote Joy executes
>> 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.
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 toWhat makes this so effective is that it is the local program that
>> 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.
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, andI think that this feature *should* be included in Joy early in
> 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?
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 whatOn the contrary, it is preserved perfectly, at least in the
> extent the concatenative semantics suffers.
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