Using `key this`, `observer this`, `signatory this` in template-local let clause causes infinite loop.

I confirm that, if this is a bug that has security implications, I already contacted [e-mail] and followed the responsible disclosure policy.

I confirm that this is not a question or a request for technical support by the community, for which the Daml forum is available.

Affected Daml version

2.0.0

Bug description

Using the expression key this in a template-local let clause seems to cause some sort of infinite recursion.

To reproduce

1. Create a daml project with the below Main module.
2. Open the Script view of the script.
3. Enjoy the sound of your laptop fans spinning as the scenario service maxes all your CPUs.
4. Wait patiently for the message "Scenario service backend error: BErrorClient (ClientIOError (GRPCIOBadStatusCode StatusDeadlineExceeded (StatusDetails {unStatusDetails = \"Deadline Exceeded\"})))" appears

module Main where

import Daml.Script

template T
  with
    p : Party
  where
    signatory p
    key p : Party
    maintainer key

    let k = key this

t = script do
  p <- allocateParty "p"

  submit p do
  createCmd T with p

Expected behavior

The same thing as if the let clause read let k = p. Ie the script view appears.

Additional context

[sofiafaro-da]

We are not adding warnings for everything that could loop infinitely – this is not possible in theory nor in practice.

I think it’s pretty clear that this is an infinite loop:

template T
  with ...
  where
    signatory (signatory this)

And this is an infinite loop that doesn’t look like it:

template T
  with ...
  where
    signatory x
    let foo = signatory this

Unfortunately adding a warning in the latter case is difficult, even for a basic thing like detecting key this and signatory this, and is at best an approximation.

I agree with @akrmn (and others in the language team) that the problem here is the template local let syntax, since it creates a false impression of the semantics. I’m in favor of deprecating it and encouraging people to write global functions instead, where the flow of computation is much more explicit.

[stefanobaghino-da]

OK, I would not try to fix the semantics. Furthermore, lazy semantics only here seems confusing.

I would say to move on with “better error message at runtime and clear documentation of the semantics” to be acceptance criteria to consider this closed.