Predefined (static) outports

[emil14]

Is it possible/makes sense to have IIPs for outports?

Might be related to #124

[emil14]

No

Because the only use-case for that is "I want exact specific value for this connection(s)" and givers/triggers/static inports solves this

[emil14]

Yes

It does make sense. It makes programming simpler. E.g. for the "program that does nothing" (#221) it takes really almost nothing. The use case is "I want exact known value at THIS place in the network but I HAVE TO use triggers for that" which means creating new connections, nodes, etc.

Interesting thing is that as opposed to static inports outports doesn't have to be of the same (comparable) type. For the "hello world" program we want "println" output code zero and not "hello world" string. Int and string are obviously different and not compatible types. That's okay. We sure must still ensure compatibility between outport and its reader inport.

Question is how this must be properly implemented

• By "desugaring" at the hevel of the source code - i.e. adding trigger nodes and connections to source code representation and then compuiling it
• At the level of IR generation. I think static inports works like that now.
• Move that complexity to the runtime level and let the network manager replace the messages based on connection info (it sounds like an interception. Otherwise there will be "interception" outside of the interception.

Offtop: interceptor does not do unpacking of the messages even though we kinda intercept them and do something with them. Should we fix that?

---

BTW this new feature will actually simplify program structure and not make it more complex. Instead of:

type Connection struct {
	SenderSide    SenderConnectionSide
	ReceiverSides []PortConnectionSide
}

// SenderConnectionSide can have outport or message as a source of data
type SenderConnectionSide struct {
	MsgRef *EntityRef // if not nil then port addr must not be used
	PortConnectionSide
}

type PortConnectionSide struct {
	PortAddr  ConnPortAddr
	Selectors []Selector
}

We would have just:

type Connection struct {
	SenderSide    PortConnectionSide
	ReceiverSides []PortConnectionSide
}

type PortConnectionSide struct {
        MsgRef *EntityRef // if not nil then port addr must not be used
	PortAddr  ConnPortAddr
	Selectors []Selector
}

[emil14]

• What are other usecases except hello world?
• Can we implement it later?

[emil14]

I'm not sure since I don't have much time to dig into this one but looks like we're fine with constants