run is collecting IO.done value when it's a fun state

[steinerkelvin]

This panics on the second run because the first one is collecting/clearing the state of Plist.

ctr Nil 0
ctr Cons 2

fun PList 1 {
  !(PList $(Get)) = $(IO.load λx $(IO.done x))
} = $(Cons #111 $(Nil))

run {
  $(IO.call @PList $(Tuple1 $(Get)) λx
  $(IO.done x)
  )
}

run {
  $(IO.call @PList $(Tuple1 $(Get)) λx
  $(IO.done x)
  )
}

cc @racs4

[steinerkelvin]

Actually, even two loads in sequence fail:

ctr Nil 0
ctr Cons 2
ctr Get 0

fun Common 1 {
  !(Common $(Get)) = $(IO.load λx $(IO.done x))
} = $(Cons #111 $(Nil))

run {
  $(IO.call @Common $(Tuple1 $(Get)) λx0
  $(IO.call @Common $(Tuple1 $(Get)) λx1
  $(IO.done #0)
  ))
}

[steinerkelvin]

Ok, this can be avoided by dupping the loaded state mannualy:

ctr Nil 0
ctr Cons 2
ctr Get 0

fun Common 1 {
  !(Common $(Get)) = 
    $(IO.load λx
    &{x1 x2} = x;
    $(IO.save x1 λ~
    $(IO.done x2)
    ))
} = $(Cons #111 $(Nil))

run {
  $(IO.call @Common $(Tuple1 $(Get)) λx0
  $(IO.call @Common $(Tuple1 $(Get)) λx1
  $(IO.done $(Tuple2 x0 x1))
  ))
}

The problem is that the contract's state would get linearly dupped away from the actual data by calls to $(Get).

Maybe we could manage the dups internally on calls to IO.load but that seems kinda hellish?

[steinerkelvin]

Maybe IO.load and IO.save should be replaced by something like IO.dump/IO.copy and IO.swap, respectively:

IO.dump/IO.copy would work like IO.load but would make a full copy of the contract state that you can inspect and use freely, leaving the actual state alone. This would be an expensive operation that should be avoided.

Usage of swap would be:

(IO.swap λx !(f x)  λ~ ..)

meaning you can only access the actual state of the contract if you consume it and immediately provide a new one.

But we would be still missing a way of peeking into the state of the contract.

[VictorTaelin]

Very good job, @quleuber.

[VictorTaelin]

Can you test on all the examples you gave, plus as many more as possible?