It seems reasonable. I'm not sure how much the connection code will like this, but it's worth trying.

It can be made to like it 😊

@baggepinnen are you then implying that the following JSML code:

connect(y, u)
u1: analysis_point(y, u)

should generate code that looks like this:

connect(y, :u1, u)

...after this issue is resolved? A key point here is that connect statements (at least in JSML) are unordered. I don't know about MTK, but if I understand you correctly, these are semantically different in MTK (or at least should be):

connect(u, :u1, y)
connect(y, :u1, u)

So during JSML code generation, I would follow the ordering in the analysis_point statement when generating the MTK code, right?

They are semantically different in MTK right now, but we would most of the time have the required information to enforce that an output is connected to one or several inputs, so we could also decide that the order is unimportant, I.e., the two connect statements are semantically identical and error if the user passes anything that isn't an IO connection.

How will this handle multi-connections?

connect(x, :u1, y, z)

How will this handle multi-connections?

It is already handled by the analysis-point code, as long as at most one connector is an output and the other ones are inputs. The semantics then are

connect(output, input1, input2, input3)

expands to

output ~ input1
output ~ input2
output ~ input3

@ggkountouras I just want to clarify that there is a connect statement in both MTK and JSML. I just want to clarify that multiple connectors are supported in JSML already. I can't comment on what MTK supports. But I just wanted to flag that code fragments here require some context given that connect appears in both contexts.