Re-think the `Mints` constraint

[carlhammann]

I'd like to know a bit more about the design decisions that led to the current type of the Mints constraint, which is this:

  Mints ::
    MintsConstrs a =>
    Maybe a ->
    [Pl.MintingPolicy] ->
    Pl.Value ->
    MiscConstraint

Specifically:

• Why is the second argument a _list_of minting policies?
  • Why not a list of policies together with their redeemers? When (apart from the Nothing case) does it make sense to give the same redeemer to all policies?
• There's redundant information in the constraints that can possibly be mismatched: The asset classes of the value to be minted must be a subset of the hashes of the provided policies.

I'd like the type of the Mints constraint to be something like this:

  Mints ::
    MintsConstrs a =>
    Maybe a ->
    Pl.MintingPolicy ->
    Pl.TokenName ->
    Integer ->
    MiscConstraint

The intended meaning is "With the given redeemer, ask the given minting policy to mint a given number of tokens of the given asset class". Is there a fundamental reason why this is impossible?

[carlhammann]

This is also somewhat relevant in the context of issue #165, as it would make the implementation of the function sameConstraints described there a little easier.

[florentc]

I have always found it weird too. The idea of several minting policies is to mint values with multiple assets that belong to different policies but, indeed, there is only room for one redeemer anyway in the current constraint. Also, why not split it into different Mints constraints. I agree with your proposition :+1:.