Disallow `state`, `var` and `pub var` decls in macro expansion?

[mitchmindtree]

This is a follow-up to the discussion in #772 starting here.

I guess if we decide to not allow declaring vars and pub vars in macros then I could not merge this PR and just change the integration apps to not do that?

@freesig I'm still open to the idea that they might be useful, but I think in the use-case you gave I'd probably write it a little differently, e.g.

• Use a type to group a signature with a pub key, something like this (probably a better name for this type):

  type SigWithPubKey = {
      sig: std::lib::Secp256k1Signature,
      pk: std::lib::Secp256k1Signature,
  };

• Change the macro to just do the signature verification, change its name to @verify_sig or similar, and receive a sig+key pair as input.
• Add a dedicated macro for the __mut_keys_len() == 0 condition like @no_mutations() or something.
• Change the predicates to declare the sig+key pair and state separately, e.g. something like

  predicate Burn {
      pub var token: PredicateAddress;
      interface T = Token(token.contract);
      predicate I = T::BurnI(token.addr);
      var sigkey: SigWithPubKey;
      state nonce = T::storage::nonce[I::key];
      @verify_sig({I::key, I::amount, token, nonce'}, sigkey, I::key); 
      @no_mutations();
  }

  I guess it's a bit more verbose, but feels a little more readable? :thinking:

[freesig]

Yeh I can clean that up a bit. One area this does come up is with authentication. We currently are doing:

    var auth_addr: PredicateAddress;
    @auth(auth_addr; key; auth::@burn());

Technically we could put the var inside the macro as it's only use in there. This avoids the user of the @auth library macro needing to know that they have to pass in this var which they never even use. This is especially a problem because there's no type signature on macros.

I do see the other side of this though, you can really look at it both ways (all inputs as args to a giant function vs vars used within scopes).

I think we should also include vars declared in other files in this convo (if that's actually possible atm).