User:Igor Zhuravlov/Data teleport
Jump to navigation
Jump to search
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
- Free (since J901) primitive t. may be used as name for t verb implementation.
- 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
- Extended forks, one way to overcome trains dataflow restrictions