Component configuration (predefined ports, IIPs, static ports, static messages)

[emil14]

Compiler level

Allow IIPs-like behavior at compiler level. Let every inport have predefined message that will always be send to that port

The idea in pseudo-code:

component A {
  ports { x, y int }
}

msg p = 3.14

node a = A({
  x: 42
  y: p
})

Runtime level

At runtime we can have "effects" or use some std-component for represent real node that interacts with the program's network.

Motivation

• Const-nodes/generator components adds extra mental overhead to the user
• J.Paulm already solved this problem via IIPs, not extra nodes (btw this should work the same way I wanted first under the hood)

---

See #118 where I describe problem that is related to this

[emil14]

No triggers, only lockers

Since we don't have this "special meta data" for specific components (like generator components) and all we have is ports and possibility to map them with IIPs, it turns out we no longer need triggers. All we need is lockers. Because locker is a trigger that takes its outport data from its inport.

Example:

# print "42"
sig -> locker.sig
locker.in.v = 42 # IIP
locker.out.v -> printer.v

Configuration object

This is how conf of component can be represented:

ConfObj { IIPs, deps }
IIPs { in, out PortIIPs }
PortIIPs { [portRef]: msg }
portRef { name string, idx int }
deps { [dep]: DIExpr }
DIExpr {
  componentRef {pkg,name} 
  cfg ConfObj
}

[emil14]

Conclusion

• Generators (generators without inports) are bad because they have all the problems of static ports but also brings new abstraction
• Triggers are bad if they work like this: trigger accepts signal and sends the data. They are ~ok if once the signal is there they start to send messages and never stops
• Lockers are good but they can't solve the problem by itself. Something like generators/infinite triggers/static(predefined)ports is needed

Infinite lockers or static ports?

The difference is

• trigger has some meta data so it's not usual component (or every component can have such metadata (which looks like ad-hoc solution)
• static ports can be part of any component's configuration and feels like a universal mechanism

Pros and conds

The problem with static ports is that it's possible to write a program/package that causes an endless loop by using a componentn with all (or some specific) ports as a static ports.

On the other hand it is possible to create an endless loop with trigger by connecting it's outport to it's inport

It's also possible to create endless loop in almost any language btw (which is itself not an argument)

1. Endless loop with a (infinite) trigger is more explicit (probably) but it's adds complexity to program's structure
2. It's possible to create endless loop anyway (without triggers) and it's very hard to track this with compiler

Possible solution

Go for static ports but implement compiler check that there must be N < M where N is a static ports and M is all ports. Because it makes (check that statement) no sense in using component with all ports static because it leads to endless loop

Both triggers and static ports adds some complexity to the program but static ports are not ad-hoc (special kinds entity) solution and it makes the program (user's source code) simpler (less nodes in the network)

[emil14]

Closed in favor of #453