Being able to refer to one particular variable state outside of definition

[Denis Merigoux]

Edit: current progress

• access an intermediate state of a variable within another definition in the same scope
• access a specific state of a variable within a definition of another state of the same variable, with the specific warning described below (the access is trivial, the warning complex to implement)

The problem

Suppose we have the following variable declaration :

internal foo 
  state one
  state two

Since #114, when referring to foo outside the definition of foo, you'll actually pick foo.two in the last state. But in real-world examples, you still need sometimes to use an earlier state of foo outside of the definition of foo. Right now, there is no way to do that with the surface syntax, even though under the hood foo.one and foo.two are two separate variables with separate dependency tracking, etc.

Solution

A proposed solution is to add a surface explicit syntax to refer to a particular state of the variable outside of its definition. The syntax, at the level of expressions could be like that :

foo # refers implicitly to the last state as currently
(foo state one) # refers to the result of the definition of state one of foo

[Denis Merigoux]

@AltGr what do you think ? Do we proceed with the syntax committee for this next week ?

[Louis Gesbert]

Yes! Maybe foo at state one ?
Important note: this should be available only within the scope where the variable is defined.

[Louis Gesbert]

Hm I have an additional interrogation here:

• Accessing foo state one from another definition within the same scope → ✅
• Accessing foo state one from another scope → 🟥
• ... but what about accessing foo state one from the definition of foo itself (or more precisely, an earlier state thereof) ?
  • My idea at the moment is to allow it as long as it's a reference to a strictly earlier state
  • Another option is to forbid it entirely, it might bar some use-cases (?) but it keeps strong the current meaning that a state always refers (implicitely) to the state just before. Users without a clear knowledge of this might start referring to the previous stage explicitely, which would break the code if a new state is later inserted in-between.

[Denis Merigoux]

Hm I have an additional interrogation here:

* Accessing `foo state one` from another definition within the same scope → ✅

yes !

* Accessing `foo state one` from another scope → 🟥

yes !

* ... but what about accessing `foo state one` from _the definition of foo itself_ (or more precisely, an earlier state thereof) ?
  
  * My idea at the moment is to allow it as long as it's a reference to a strictly earlier state
  * Another option is to forbid it entirely, it might bar some use-cases (?) but it keeps strong the current meaning that a state always refers (implicitely) to the state just before. Users without a clear knowledge of this might start referring to the previous stage explicitely, which would break the code if a new state is later inserted in-between.

Very good question. I would allow referring foo state one from the definition of foo, BUT raise a warning when you detect that the user has written foo state one instead of just foo with the caveat you describe.

[Denis Merigoux]

The syntax committee agrees with the proposed syntax (meeting of Jan 30th, 2024). They also decide on the compiler issuing a new warning on the following basis : if for variable x you're at some point in an expression referring to a specific state x state foo, then in all other occurences of x in the same expression, you also have to pin the state.