Syntax for physical connections

[cmnrd]

While physical and regular connections are clearly distinguishable in the diagrams, this is not the case in the LF syntax. The difference between

foo.out -> bar.in

and

foo.out ~> bar.in

is hard to spot, especially when skimming over a large program. We also got this feedback from reviewers. At first, I didn't take the feedback very seriously, but now it happened several times to me that I missed a physical connection when reading LF code. The more I notice the problem, the more I think we should reconsider the syntax.

Maybe a better alternative is to add an explicit physical qualifier like so:

foo.out -> bar.in physical

I think this would blend in nicely with the after delay syntax. What do you think?

[lhstrh]

As a personal preference, I like it when code can be read out loud and make sense (or get as close as possible to making sense). In that light, I would not put the physical keyword last but first, as a modifier of the entire connection statement.

[edwardalee]

How about something like:

  foo.out ~~> bar.in

[lhstrh]

How about something like:

  foo.out ~~> bar.in

This I also like...

[cmnrd]

I agree that it is a good goal to be able to read the code out loud. Interestingly, I find this easier when physical is written in the back. Here is how I would read different cases:

a -> b           // a connects to b
a -> b after 1s  // a connects to b after 1s
a -> b physical  // a connects to b physical(ly)

How would you read physical a -> b? I find it difficult to make sense of it, but maybe I am missing something.

~~> is indeed more distinguishable from -> than ~>. However, I think that the physical keyword would be even more obvious.

There is also another argument for using an additional modifier like physical instead of a dedicated --> symbol. -> is an operator and in any programming language it is good practice to have only one operator for performing a certain operation, not multiple closely related. In my view, -> is a connection operator and its sole purpose is to establish connections between its left and right side arguments. Those connections might have additional properties (after delay, physical) which are additional arguments (or modifiers) to the operator. If we have -> and ~~> then we have two operators performing the same task, just with different properties.

[edwardalee]

These are good points. I'm OK with this change (particularly if we keep it backward compatible). I would argue that the use of the physical keyword emphasizes the relationship with physical actions.

[cmnrd]

Yes, I would definitely keep the old syntax as an alternative and mark it as deprecated.

[erlingrj]

One thing to consider is that we might want to mix "physical" and "after".

a -> b physical after 10 msec
a -> b after 10 msec physical

You might argue that this pattern doesn't make sense since physical already means that it is non-deterministic or arbitrary. But I think it could have a use where you want to send an event to a downstream federate/enclave and it doesn't have to be handled at once. With physical connections there is always the risk that it randomly gets assigned a very unfortunate logical tag, e.g. 1 ns before another event which has a deadline associated with it. Adding an after-delay on the physical action doesnt quite solve this either because you might be unlucky with the new tag also.

[cmnrd]

Afaik, physical connections with delays are supported at the moment. The syntax a -> b physical after 10 msec makes sense to me. It would also be possible to extend this in the future, so that events get be better aligned with certain tags.