ExercisedEvent.choice field

Which of the following does the ExercisedEvent.choice field hold:

1. The qualified Daml type name including package id
2. The qualified Daml type name sans the package id
3. The unqualified type name
4. Something else

It is the choice name. That’s not technically related to the type name at all in Daml-LF. It’s just a single string that can have no relation to the type of the exercise arguments.

However the daml compiler generates choices such that there is always a corresponding type as well for the exercise arguments. The choice name is then the unqualified type name.

Thanks. I am a little confused at this bit though: “That’s not technically related to the type name at all in Daml-LF”.

When you write choice Foo, it’s my understanding that in the compiler front end, this gets de-sugared into a record type holding the arguments and a type-class instance defining the behavior. Are you saying that the fact that the name generated for the former matches the name in the choice declaration is just a convention rather than a guarantee, because the Daml-LF spec mandates no such correspondence (and can’t because it doesn’t specify how Daml code is translated to Daml-LF)?

When you write choice Foo, it’s my understanding that in the compiler front end, this gets de-sugared into a record type holding the arguments and a type-class instance defining the behavior.

That’s still at the Daml level. Daml-LF has no typeclasses. In Daml-LF a template is defined (among other things) by a list of choices. Each of those choices has a name, a choice argument and the implementation (and some other stuff which doesn’t matter here). There is no relationship between the name and the choice argument in Daml-LF. You can use a completely different type, share types across choices (Archive actually does that), ….

Damlc generates a new choice argument type for each choice and sets the choice name to the unqalified name of that type.

Yes, that’s what’s what I was getting at when I wrote:

Are you saying that the fact that the name generated for the former matches the name in the choice declaration is just a convention rather than a guarantee, because the Daml-LF spec mandates no such correspondence (and can’t because it doesn’t specify how Daml code is translated to Daml-LF)?

The part I was missing is that the choice name is part of the Daml-LF spec, so when you declare choice Foo you are specifying the Daml-LF choice name rather than the name of the associated type.