`If` behaviour on stuck terms

[o-santi]

Currently, the (If ...) rule on the genesis block evaluates everything that is strictly not #0 to the true branch. This includes terms that cannot reduce any further, which can cause some very unexpected behaviour when comparing objects of different types.

For example, the following code:

fun (Test x) {
  (Test x) = (If (== x #5) (Done 'yay') (Fail #0))
}

run {
  ask test = (Call 'Test' [#4])
  (Done test)
}

will silently fail. It will always evaluate to (Done 'yay') even though it clearly is not the intended semantics, because the following comparison (== {T1 #4} #5) gets stuck, and If evaluates that to true.

I do believe that we should change it match only on #0 and #1, in order to avoid javascript-esque errors like these. But I think that this raises a bigger question: what should be the norm/expected behaviour on treating stuck terms?

cc @steinerkelvin @developedby

[nicolas-abril]

Changing the If like this would break compatibility with normal HVM's if function, which implements it like the current version of the function in Kindelia's HVM.

[nicolas-abril]

I think that many people will expect thgat If behaves like C's ìf` statement does. This is not a hard barrier, but is something to consider.

Besides, having a non-complete function can bring other misterious errors. This masks the original function that got stuck and can be hard to debug. It's better than just swallowing the error without any traces, but is still not great

[steinerkelvin]

The real question here is if we should emit errors on stuck function redexes. If there are no use cases that would be made impossible we should probably do it.
@VictorTaelin

[VictorTaelin]

We did that on that other issue and it was problematic, no? I must remember the context.