Outdated syntax for STA/STAA

[lhstrh]

The CAL paper uses syntax for specifying STA/STAA that does not match what we currently have in master. Is the syntax as used in the CAL paper finalized and agreed upon, and should we just bring the code base in compliance, or do we need to build consensus? On a related note, I do think that STA and STAA are rather elaborate acronyms that are a little difficult to pronounce. Should we try to find better terminology?

[edwardalee]

I'm not thrilled about the STA and STAA acronyms and would be happy to entertain suggestions for better ones.

[Soroosh129]

In terms of syntax (assuming that we are working with STA and STAA acronyms for now), I think something like this could work:

reactor Foo {
    input in:int;
    output out:int;
    reaction(in) {=
    =} late {=
    =}
}
federated reactor {
    f1 = new Foo() {
        STA: 0
    };
    f2 = new Foo() {
        STA: 10 msec
    };

    f1.out -> f1.in {
        logical-delay: 10 msec,
        STAA: 0 msec   // or, absent-after: 0 msec
    };
}

In terms of replacing the acronyms, one possibility is to replace STAA with absent-after. I have a hard time thinking of an alternative to STA, but it could be upstream-lag or perceived-lag (or perceived-upstream-lag).

Alternative syntax using attributes (#977):

reactor Foo {
    input in:int;
    output out:int;
    reaction(in) {=
    =} late {=
    =}
}
federated reactor {
    @STA(0)
    f1 = new Foo() ;
    @STA(10 msec)
    f2 = new Foo();

    @label("Delayed connection")
    @logical-delay(10 msec)
    @STAA(0)
    f1.out -> f1.in;
}

[lsk567]

In this case, the first syntax looks more compact to me and deals with nested objects better. I think the Java-style attributes are good for short commands like @label(), @public, and @unordered.

However, we should caution against { ... } becoming too long and affecting readability. In that case, providing syntax to link a statement to an external config file might be a cleaner solution.

[edwardalee]

For naming, how about safe-lag for STA? The explanation is this: safe-lag specifies a lag (physical time minus logical time, T - t) after which it is safe to assume that upstream federates will not send messages with tags less than t.

I also prefer the first syntax. It generalizes the annotations we put on the target keyword and I think it is more readable. More importantly, we seem to be getting a growing list of possibilities for annotations that could help for using LF as a research platform. For an external file, perhaps something like this:

    f = new Foo() {file: "f-annotations.yml"}

[Soroosh129]

For naming, how about safe-lag for STA? The explanation is this: safe-lag specifies a lag (physical time minus logical time, T - t) after which it is safe to assume that upstream federates will not send messages with tags less than t.

I like safe-lag a lot.

I agree that being able to load from a config file is a great addition here that improves readability. We could, perhaps, use the discussion in #1010 to come up with a unified config file format for LF programs. If we can agree on a format, we could have a universal config: "foo.yml" convention wherever it makes sense. The configs for f in @edwardalee's example could, for example, be listed under a [f] header in the proposed TOML syntax.

[lsk567]

To revive this discussion, here I gather a list of annotation syntaxes used by other programming languages:

1. Java annotations
2. Rust attributes
3. C++11 generalized attributes
4. Python functional annotations, Python decorators

From my perspective, the Java syntax is the most intuitive one here. The above example becomes

reactor Foo {
    input in:int;
    output out:int;
    reaction(in) {=
    =} late {=
    =}
}
federated reactor {
    @Federated(sta = 0)
    f1 = new Foo() ;
    @Federated(sta = 10 msec)
    f2 = new Foo();
    @Federated(config = "foo.yml")
    f3 = new Foo();

    @Label("Delayed connection")
    @Federated(
        logical-delay = 10 msec,
        staa = 0)
    f1.out -> f1.in;
}

The attributes related to federated execution are all grouped under the @Federated annotation.

[Soroosh129]

Thanks @lsk567!

It was interesting to look at all the different syntaxes that people have come up with in these languages. It seems like each came up with a different solution, which means there is probably no perfect solution to this :)

I agree with you that among these, Java’s syntax is the most familiar and intuitive solution. I think with proper syntax highlighting, the code should be reasonably readable even with a lot of annotations.