The data teleport proposal would be good for tacit assignment. https://code.jsoftware.com/wiki/User:Igor_Zhuravlov/Data_teleport
An easy "order of execution" restriction on forks would be: v1.2 v3 v1.1 v2 v1 accessing an assignment/data teleport can only be done on verbs numbered with a higher "integer prefix". In serial code, the v1.x are executed in ascending sequence, but in parallel code, they can be executed independently. A possible but more complicated approach would be access to a data teleport location blocks until that location is filled/initialized. And a decision as to how to handle embedded teleports need be made (likely 0 t. private to its containing verb such that there are no conflicts) The order of execution restriction is not cumbersome at all because v2 above can be t. v1.2 (t. 0)Adv v1.1 v2 0 t. v1 As to self effacing names, I'm not too sure of the use cases. Can you use it in explicit verb for y:: ? is data::&i. a useful recommendation? should it only be considered for large nouns? On Tuesday, September 14, 2021, 10:39:31 a.m. EDT, Michal Wallace <[email protected]> wrote: what's up with this new `name::` syntax? I have no problem with the concept, but I have a different suggestion for what `name::` should mean: a verb that assigns the variable with that name. That seems like a much more commonly wished-for thing (assignment in trains) : https://code.jsoftware.com/wiki/System/Interpreter/Requests#Support_assignment_in_tacit_expressions Could you use `name:.` instead for self-effacing names? It's even got a mnemonic... The big colon followed by the diminutive period could indicate the change in status.... :) ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
