Static data parameter for components. Sugar layer. (No special case for Const)

[emil14]

The problem

There is a concept of MetaMsg passed into runtime.FuncCall at runtime - this is the way to configure function instance that gives ability to make 2 important things:

1. Pass message to Const so it can send it across receivers (this is critical feature)
2. Implement overloading for generic components (operators) like Add that must be able to (e.g.) work with both int and float (just like Go's + operator) - without overloading we would have to have AddInt and AddFloat (which is fine for many things but not builtin operators)

The thing is - we don't have this MetaMsg (probably not the best name) at the source code level. That is - end-user (a programmer) have no idea there's some payloads passed down to runtime to make it const work. That is fine by itself but lead to more complicated design of a compiler. And the complexity lives in the irgen layer.

Current solution

When we use Add<T> or someConst -> someNode.port in our components we rely on irgen to make some magic.

For Add it must create an FuncCall instance and pass "int" or "float" as a meta message inside (depending on what is T). You heard this right sir, we have to convert type argument to runtime message which is a little crazy. It would be much better to convert src.Msg to runtime.Msg instead. If only there would be an option to do it this way...

For const stuff situation not much better. We allow user to use references to const entities in the component's network just like it's a normal outport. Of course, it's not. There's no magic - runtime program must contain normal connections with normal ports. How do it? The answer is - more magic to the irgen!

What we do is we create implicit const node with Const runtime function and use const's value as a MetaMsg! As a result - user thinks he magically sends constants across the network while under the hood that's a real node.

We can do better

It's a good thing that user can do this. The problem is - complexity in irgen. More (probably) elegant design is to implement this via sugar.

The complexity arrises because or difference between two layers of abstraction. One does have concept of meta messages and other don't. While it's okay for abstractions to have different heigh levels, it's not cool to mix things in a way we did.

What if we introduce this concept of meta message at the source code level? The only problem is - what user should do with it?

This is how a program could look after de-sugaring (pi node was inserted in the source code, not irgen, irgen can be generated normally, without tricks):

const {
	pi 3.14
}

components {
	Doer(foo) (bar) {
		nodes {
			pi Const<int> {
				v: pi
			}
		}
	}
}

Of course it must be allowed for user to create exactly this program by hand, without using of sugar.

Note that we've added some syntax {...} here as a last part of node instantiation. Perhaps same (already implemented) syntax for DI could be somehow leveraged

nodes {
	pi Const<int>(v: pi)
}

Then the question is how to do both DI and meta message passing at the same time.

This feature used by user

...

[emil14]

The problem with this solution is that the only problem this solves for end-user is to passing static data inside sub-components. This is already solved with ports and without the problem of losing the flexibility. Once we go this way we have a problem that if component defines some static field we cannot make it dynamic. "Low level" languages are too flexible in comparing to this