Newton Invariant Signature ambiguity

Relevant conversation https://psm.slack.com/archives/D0NTASB6X/p1488489574000016 which is copied at the bottom of this issue

If there are multiple invariants with same signatures, then the Newton API call will just return the first invariant whose signature matches the set of parameters passed in. In the context of a sensor platform, since each type represents a signal, we would expect each invariant to have a unique signature (after https://github.com/phillipstanleymarbell/Noisy-lang-compiler/pull/106 is merged).

However, should the hardware manufacturer, for some reason, want this feature, we should examine how this can be achieved. If it cannot be achieved, then we need to make a pass to detect if there is any two invariants with identical signatures.

Convo:

Hmmm I think I am encountering a situation where I previously thought of the need for tagging. I have the following invariant.

{
    period >= 3 * second,
    period <= 9 * second
}```
and this pendulum code in C.
```    acceleration prevXacceleration = (acceleration) readFromXAccelerometer();
    time durationInSeconds = 1000 * 30; // thirty seconds
    time startTime = readFromSystemClock();
    time period = -1;

    int swingCount = 0;

    while (readFromSystemClock() < startTime + durationInSeconds)
    {
        acceleration xAcceleration = (acceleration) readFromXAccelerometer();

        if (prevXacceleration * xAcceleration < 0) {
            swingCount++;
        }

        if (xAcceleration != 0) { // do not double count the change
            prevXacceleration = xAcceleration;
        }

        if (swingCount == 2) {
            period = readFromSystemClock() - startTime;    
        }
    }

    printf("detected %d swings in the pendulum\n", swingCount);

[4:21]
There are 3 variables that match to the SimplePendulum invariant because they are of type time, but the programmer only wants to check the variable period with the invariant. Checking all three of these variables with API call will result in 3 separate API reports, and the programmer will have to discern which API report is relevant. If this is the case, the programmer has the burden of matching the variable period to SimplePendulum with tagging or this following method I just thought of now, which doesn't completely solve the problem, but should help.

The host language can support, in addition to base signal type, a base signal type that can be ignored by the host language compiler when making a call to the Newton API. For example, instead of acceleration, write #acceleration, which tells the C compiler not to consider the variable of this type when making checkNewtonApiSatisfiesConstraints call. So the declarations of time type variables in the above C code can change to
```
#time durationInSeconds = 1000 * 30; // thirty seconds
#time startTime = readFromSystemClock();
time period = -1;
```
, and the C compiler will only consider period variable when making a call to Newton API. The problem with this approach is that it still requires the programmer to have SOME sense of what the hardware manufacturer put into the Newton description, because the programmer doesn’t know ahead of time whether the hardware manufacturer put invariants relevant to startTime or durationInSeconds (edited)

[4:24]
Furthermore, another ambiguous case arises if there is another invariant

ComplexPendulum: invariant(period: time) ....

, in which case we would have multiple variables that match to multiple invariants. This particular invariant can be avoided if we prohibit having multiple invariants that can have the same set of parameter Physics types, but doing so will restrict the expressiveness of Newton. Note that this ambiguous case is not handled by the new method I suggested above (edited)

[4:26]
One way we could mitigate this issue is to make the programmer name their variables period, that requires the programmer to know that invariant parameter is named period, which was the whole point of not implementing tagging in the first place.

phillipstanleymarbell / Noisy-lang-compiler

Newton Invariant Signature ambiguity #107