Using tuples in SDF behavior instead of currying

[ricardobonna]

In CSDF, we are using [(c, p, f)] for the actors' behavior and for SADF we are using Signal (c, p, f). Perhaps it would be interesting to define SDF actors' behavior with (c, p, f) instead of c -> p -> f? I don't know if this change would decrease performance, but it would definitely increase consistency between the three MoCs.

[ugeorge]

Based on the discussion with @ingo-sander we need to further study this issue, so treating it is postponed for later.

Meanwhile we can study alternative solutions, including yielding curried functions in CSDF.

[ugeorge]

After giving it a long thought, I came to the conclusion that as it is right now the user API is ideal and should stay that way. This means:

• SDF process constructors take curried inputs: actorSDF :: Cons -> Prod -> Function -> .... This way it is possible to describe actors with production/consumption rates without caring about the function, and make use of partial application.
• SADF constructors, at lest the ones with fixed rates, take also curried inputs. The reason remains the same.
• SADF scenarios are passed as tuples. This way the designer makes use Haskell's syntax sugaring for tuples to define scenarios in an intuitive way. Thus we avoid the use of complex wrappers that might raise some designer eyebrows.
• CSDF scenarios... now this is debatable. If we leave the latest modification, i.e. actorCSDF :: [(Cons, Prod, Function)] -> ... then we stick to the concept of "scenario" in the sense of SADF, and at least from the user side, it would create a clean & compact code. If we revert it though, we would be able to use partial application like for SDF, on the other hand the user would have to separate the rates from the functions, practically forcing her to "count" the positions in the list. Needless to say, that is error prone.

So, if everyone agrees, I will close the issue for now as "invalid". I am keeping it until tomorrow if anyone has any objections.

P.S.: coherency among MoCs is not an issue for the Shallow library, as it is a pragmatic library itself and user experience is dominant. However, we can fiddle with these concepts more in the Atom framework, as I already started.

[ugeorge]

The issue has been brought up again in the context of multiple API-breaking changes in 4.0.0. We now discuss if this is worth being one of them.