Unified `submit`

Questions
,
1

Is there a specific reason why we have two “submit” implementations: one for single party and one for multiple ones?

According to the docs for IsParties (Prelude — Daml SDK 2.7.6 documentation):

Accepted ways to specify a list of parties: either a single party, or a list of parties.

I played with this a bit and got the following code:

submit : IsParties p => p -> Commands a -> Script a
submit isParties commands = do
  let parties = toParties isParties
  case parties of
    [] -> error "Specify at least on party."
    [party] -> party `submit` commands
    _ -> submitMulti parties parties commands

This seems backward compatible to me.

1 Like
2

We need two implementations to express things like submitMulti [alice] [public]. That leaves the question why we don’t allow submit [alice, bob] as an alias for submitMulti [alice, bob] [], to which I think the answer is that we expect that to be a rarer use-case so the potential confusion isn’t worth the extra convenience in the cases where that’s what you actually want.

2 Likes
3

As for “that seems backwards compatible to me”, I think it’s worth pointing out that generalizing types is not always backwards compatible and can require extra type annotations.

A good example here would be generalizing submitMulti to submitMulti : (IsParties a, IsParties b) -> [a] -> lb] -> Commands c -> Script c.

In that case,

submitMulti [x] [] …

would fail to typecheck since it cannot infer the type of the empty list.

You have to do a bit more work to construct an example where your generalization would require an extra type annotation but you should be able to come up with one.

1 Like