Replace interceptor's struct fields reading and array index reading with components

[emil14]

We use triggers to implement static inports. Why don't we use components to implement record fields and array elements reading? It would simplify program structure.

The problem is in langs like go when we say v.x we do expression where v and x are operands and x is not a string literal. If we introduce components then we got to create strings for that. It's either user creating str consts or compiler somehow generating that stuff.

[emil14]

Sugar

Since records are go maps with string keys and arrays are slices, I see no problem in having str and int constants inserted in the connections as a proxies that unbox values from structured messages. There are normal and de-sugared form of a program (HL repr). Normal form might contain things like "rec field" or "arr idx" fields in connection structures but desugared must not have it (actually it can, but we will ignore them). OTOH desugared version will contain extra connections to those special (un)box components

Upsides

• More simple network manager, no "selectors"
• We can use exact same components that we use for maps and slices but with compile time checks

Downsides

How to implement expressions like x[0].a? I mean, do we have 2 components one for records and one for arrays or one universal typedUnboxer/Selector? If we have special unboxer for records can it eat stuff like a.b.c.d.e or just a? If we have universal component then it must parse strings at runtime which is very bad. If we have separated record and arrays components then we gonna have chains of implicit unboxers that we gonna see if we log stuff. That also means more work at connector (network manager) level, more pointers passing around, more loop iterations.

[emil14]

https://github.com/nevalang/neva/discussions/369