Array outports indexing

[emil14]

Case

For tasks like "subtract numbers from first to last" where:

1. Arguments count unknown
2. Order matters

We need a way to represent ordered variadic arguments

Problem

Imagine some component with an array-outport in a module's network. It's dangerous to refer specific indexes of that outport because we don't know how many indexes will be used inside that component.

Another case is when some module has an array-inport. It's dangerous to refer some specific indexes of that inport because we don't know how many indexes will be used by parent network.

But port reference assumes some index!

Actually these two cases are the same though we talking about outport in the first one and about inport in the second. This happens because for module's network - inport is actually an outport, the port to read from!

---

UPD: array ports are like variadic arguments / rest in Go/TS. We shouldn't use specific positions args[2] from ...args as well as we should't use results = returnList(); results[2]. By using only args/results as is we are safe. This is what bypass is!

[emil14]

Array bypass solution

Just forbid array outport indexing and introduce new type of port reference / connection - "array bypass". It must be used when we want to connect some array-outport with some array-inport. Both part of the connection must be array-ports.

Problems

• Makes hard to implement routing #38
• Impossible to send specific elements to nodes inports (use normal ports for that?)
• Could be hard to compute port elements count #41

[emil14]

Only array-inport indexing

Allow only referencing array element if its inport

Problem

1. Probably not solves the routing problem
2. It could be impossible or VERY hard to figure out incoming connections count (e.g Parent network could use bypass connection)

[emil14]

Only allow if incoming connections count is known

• if it's clear how parent network uses component
• if it's clear how many elements submodule uses

Problems

• Doesn't solve routing problem (there should be some operator for routing)
• Makes modules less reusable (module with arr-ports indexing could not be used by some networks)
• Makes compiler more complicated

[emil14]

Don't implement array ports

Just use List

Problems

• Synchronous flow (must accumulate elements into single peace before processing, must accumulate new list before passing further)
• Doesn't solves routing problem (bypass also not solves it)
• FBP has array ports

[emil14]

Allow array outports

Just aware programmer that array-outports must be used with caution

Pros

• Solves the routing problem
• True FBP

Cons

• Possibility for runtime blocks
• More testing needed
• Can't claim that "if it compiles it runs" any longer

[emil14]

Strong type system

Introduce some complicated type system that will be able to figure out complex cases for even operators. Especially it must answer the question - how many port elements this operator will use?

[emil14]

Only N:N

Allow arr-ports and outports to be only 1:1 inports to outports

Problem

TODO

[emil14]

Check for holes only

If there is a[2] then there must be a[0] and a[1]. Because if there is a[3] then there is 0,1 elements that must be used because someone is must be sending values to those ports.

Problems

1. Unread values - If there's n ports filled but only <n ports are used outside (could be solved in #54)
2. Unfilled values - if there's <n ports filled but n ports used #55

[emil14]

Make sure indexing errors are startup errors

Allow outports indexing but make sure any indexing errors will happen at startup of the program

TODO think how to implemnt

[emil14]

Default/empty values

Always use all the outports but send some empty values to the ones that are not needed.

Example: p1, p2, p3 -> router -> r1, r2, r3, r4. There is no value for r4 but router will send some default value there

Problems

• Computations without any sense