As per the screenshot:
just trying the most basic operation (addition), but seems the type inference can’t infer anything.
In order to compile a node for vvvv the VL type must be closed since vvvv can not deal with generic nodes and the type system in VL does not know about the vvvv world.
So you have a few options, either annotate the type of any inlet/outlet or use the non-generic version of the the + operator, e. g. Float64 in this case.
MM ok then why just having input->output connected then works, since it should fall in the same case?
I agree this is confusing. But let’s first try to explain what’s happening:
- The type inference in VL is by default kinda lazy. It tries to keep type constraints as long as possible so nodes can be re-used for different data types. Let’s call nodes which contain type parameters “open” and those which do not “closed”.
- On the other hand the entry point (= root patch) of an application should not contain any type parameters. In order to achieve that patches can explicitly be marked as “closed”, telling the type inference to avoid creating type parameters. In case there’re still some left in a patch we decided to treat it as an error should the parameter occur on a node and as a warning should it occur on an in- or output (fields included). Since we treat it as an error on nodes, those nodes won’t make it into the target code, therefor no constraints will apply and so we can safely substitute the parameter with whatever we want - Float32 in our case.
- In a VL standalone world only one such entry point would probably exist, but in the VL embedded world each vvvv node wrapping VL must be treated as such an entry point and therefor the wrapped VL node must be “closed”. Without this rule the vvvv wrapping mechanism would have to play a very stupid type guessing game which it could sometimes win and sometimes not - leading to much more obscure errors.
So what are our options:
- Leave the language rules as they are and make warnings and errors better visible. Let’s say we use orange and red coloring. We’d immediately see that our template patch would start out with orange in- and outputs, telling you that you can’t use type parameters in a “closed” patch. A little better than the situation now, but still confusing.
- Another option would probably be to treat type parameters on in- and outputs in patches marked as “closed” as errors, in which case the Template patch (input connected with output) would only work with a type annotation attached. I remember that one argument against this was that users coming first in touch with VL would immediately miss out of the type inference as the type on the input would already be fixed to say Float32.
- Remove the restriction that nodes need to be “closed” - but that like I already said could lead to very strange scenarios or in a lot of boiler plate forcing the user to annotate all pins.
There’re probably more viable options which we should certainly collect and discuss (@gregsn).