Can't compile without strict typing of inport

[swork1]

Describe the bug Can't compile code without strict typing of inport on flow example below Sworktest

To Reproduce Steps to reproduce the behavior:

1. Run

   
   flow Main(start) (stop) {
   nodes {
       Sworktest
       StreamPort<int>
       Println
   }
   :start -> [
       (1 -> streamPort[0]),
       (2 -> streamPort[1])
   ]
   
   streamPort -> sworktest -> println -> :stop
   }

flow Sworktest(in) (out) { nodes { Add } :in -> add -> :out }

**Expected behavior**
Run and print out `3`

**Fix**
Adding a type to the inport Sworktest like `Sworktest(int stream<int)(out)` allows the example to compile

[emil14]

Here's is the error that I got

Incompatible types: in:in -> add:UNKNOWN: Subtype and supertype must both be either literals or instances, except if supertype is union: expression any, constaint { idx int, last bool, data int }

I must admit that add:UNKNOWN part is very confusing and error message overall far from perfect. However, what it tells is that this connection right here

:in -> add 

Is invalid because add wants { idx int, last bool, data int } (this is what stream<int> actually is) and you send any to it. It's any because you didn't specify port type, which is ok for many cases but here you have to do it.

So your signature must be flow Sworktest(in stream<int>) (out).

---

If this behaviour confuses you like "why am I have to specify port in one case and not the other" here's the answer - compiler doesn't have any type inference. It's questionable if it should but this is the case at the moment. Using any as a type for port without port specified is not inference. No smart stuff going on here :) That's not the problem for me personally but if it's for you (just in case), then you might specify types all the time like Dorian likes to do it.

---

However, there's a PR I made today that improves this error just a little bit (it removes the UNKNOWN word from message that comes from the fact that we didn't specify add node's port)

https://github.com/nevalang/neva/pull/676

[swork1]

That helps definitely. I wasn't sure if there was type inference or not (not saying there needs to be that is a design discussion)