Warn about unused ports, actions and timers

[cmnrd]

The validator should produce a warning if ports, actions or timers are unused. This can help to mitigate some problems that we would otherwise only notice when running the program.

Here is a proposal for the rules that should be checked:

• timers should be a trigger or source for at least one reaction
• actions should be a trigger or source for at least one reaction and an effect for at least one reaction
• ~~inputs should be a trigger or source for at least one reaction (if not connected to an input of a contained reactor)~~
• ~~outputs should be an effect for at least one reaction (if not connected to an output of a contained reactor)~~

[edwardalee]

I don't think we should warn about unused ports. It is actually an important aspect of actor-oriented classes to be able to have unused ports. They are particularly useful when combined with inheritance. There is a particularly beautiful theory around this. See this paper. A simple use case is to define an interface that has a variety of implementations.

[lhstrh]

I think warning for unused actions/timers makes sense. For reasons already mentioned by @edwardalee, let's not do this with ports.

[cmnrd]

I sometimes forget to connect ports, and most of the time we want all ports to be connected. I think there are some exceptions, and the point that @edwardalee makes is valid. I am wondering now if it would make sense to introduce syntax to mark ports as unused (or as pure interface ports). This would allow us to produce warnings on unused ports, but also allow the programmer to explicitly mark ports that are deliberately unused (and silence the warning).

[oowekyala]

I am wondering now if it would make sense to introduce syntax to mark ports as unused (or as pure interface ports). This would allow us to produce warnings on unused ports, but also allow the programmer to explicitly mark ports that are deliberately unused (and silence the warning).

Maybe a simple solution would be to react to a // suppress(unused) comment.

Maybe at some point we should anyway have an extensible attribute/annotation syntax, which can apply to many code constructs (something like Rust's #[allow(unused)]). This would be useful in other situations, and it would make the core language smaller.

[lhstrh]

I’m just unsure that an unused port should trigger a warning: if I create a base reactor class with some ports meant to let subclasses add reactions that deal with those ports, then the presence of the unused ports is deliberate.

If I create an abstract class with unimplemented methods in Java, then I also don’t get warnings. Perhaps there needs to be something similar to Java’s abstract keyword to label classes as unfinished implementations, so the warnings only get triggered for reactor classes that are meant as full implementations?

On Tue, Oct 19, 2021 at 7:26 AM Christian Menard @.***> wrote:

I sometimes forget to connect ports, and most of the time we want all ports to be connected. I think there are some exceptions, and the point that @edwardalee https://github.com/edwardalee makes is valid. I am wondering now if it would make sense to introduce syntax to mark ports as unused (or as pure interface ports). This would allow us to produce warnings on unused ports, but also allow the programmer to explicitly mark ports that are deliberately unused (and silence the warning).

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/lf-lang/lingua-franca/issues/625#issuecomment-946780349, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYD47HIDPEEKOMWEAA2PBLUHV5Z7ANCNFSM5GGQMPTA .

--

-- Marten Lohstroh | Postdoctoral Researcher University of California | 545Q Cory Hall Berkeley, CA 94720 | +1 510 282 9135

[edwardalee]

Abstract classes cannot be instantiated, but there are legitimate use cases for instantiable reactors with unused ports. In a subclassing relationship, the presence of inputs and outputs is co- and contra-variant, much like method parameters and return values. A subclass is a drop-in replacement for a base class even if it adds output ports (the outputs will be ignored), but not if it adds input ports. For this reason, it is legitimate for a base class to have input ports that it does not use. Think of a base class method that ignores an argument, but where the argument is important in a subclass.

[cmnrd]

I follow this argument and agree that it is a viable use-case to have reactors with unused ports, similar to unused parameters in a base implementation of a method. However, in C++ (and some other languages) with warnings enabled, we will get a warning about unused parameters if we do not mark the parameters explicitly as unused. I am wondering if this would be a useful feature in LF, too. It would prevent accidental errors where a dependency was forgotten or some reaction isn't implemented, but would allow for the legitimate use-case of having unused ports deliberately.