Skip to content
Discussions/App Development/Unified `submit`Forum ↗

Unified `submit`

App Development3 posts390 views4 likesLast activity Mar 2021
TA
Tamas_KalczaOP
Mar 2021

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.

BE
bernhard
Mar 2021

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.

CO
cocreature
Mar 2021

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.

← Back to Discussions