User:Igor Zhuravlov/Data teleport

Another way to overcome trains dataflow restrictions would be a primitive to establish a data pipe ("teleport") between arbitrary code points. Teleport has inlet and outlet fittings which are represented by separate code pieces. Some noun being placed at the inlet fitting becomes available immediately at the outlet fitting. Each inlet fitting may have any number of related outlet fittings.

A teleport can be imagined as a copula (name =. referent) but with name and referent parts which are untied from each other and which can be used separately in a functional manner.

Interface

NB. t                                                   _ 0 _
NB.
NB. Description:
NB.   Send to (dyadic evoking) or receive from (monadic
NB.   evoking) a data teleport.
NB.
NB. Syntax:
NB.   trash=. id t data  NB. inlet to send data
NB.   data=.     t id    NB. outlet to receive data sent
NB. where
NB.   id   - teleport id
NB.   data - any noun

Application

data=. 42    NB. any noun value
0 t data     NB. send a noun to teleport #0
...
data2=. t 0  NB. receive a noun from teleport #0, the following holds: assert. data -: data2

Model

NB. let's limit by 3 teleports:
tdata=: 3 # a:
t=: (3 : 'y {:: tdata') : (4 : 'y [ tdata=: (< y) x} tdata')

Discussion

Pros:

no need nouns to push through the code
no global namespace polluting

Cons:

it's like a "goto" but for data

Open questions:

output from not yet initialized pipe

Notes

May be implemented, of course, as plain J class

References

Raul Miller's user_talk with discussion and another implementation options
[Jprogramming] Explicit vs tacit with assignment, Jose Mario Quintana, 2019-11-26 23:03:43 UTC
[Jprogramming] self effacing names??, Pascal Jasmin, 2021-09-14 16:52:43 UTC
Extended forks, one way to overcome trains dataflow restrictions
GitHub jsoftware/jsource issue#59