Variant constructor matching (w/o argument) differs depending on package structure

When working with multiple DAML packages imported into one another, I found that variant constructors without arguments take a unit argument when imported from another package, but take no argument when used in the same package. The following example shows the problem:

Package 1 contains this module with a variant definition and a function f1 with a case match on the variant

module Package1File where

data AVariant = V1 Int
              | V2

f1 : AVariant -> Text
f1 x = case x of
         V1 i -> "V1"
         V2   -> "V2"

Package 2 contains a module which imports Package1File and contains an identical function f2:

module Package2File where

import Package1File -- from package 1

f2 : AVariant -> Text
f2 x = case x of
         V1 i -> "V1"
         V2 _ -> "V2"

Note that the match on V2 uses a _ for an uninteresting argument. This example code compiles when distributed into two packages, but f2 is incorrect when it resides inside the first package.

[sofiafaro-da]

Maybe worthwhile to note: The change of arity of this constructor only happens when the original package is depended upon as a data dependency. When using a full dependency the constructor match and value without argument compiles fine.

Yes, this is expected. “dependencies” use GHC’s built-in mechanism (interface files) so you have all information from the original package, whereas “data-dependencies” go back from built DALF files, and try to provide a DAML interface to LF code by adding stubs. It is at best an approximation of the original interface, and should, at this point, be thought of as something similar to using the ledger API or language bindings.

Ok, so, after looking into this and talking with @remyhaemmerle-da, it looks like we could change the way we’re compiling variants, so that “variant constructors of no input” end up as synthetic variant-record constructors where the record has no fields. We should gate this change by LF version at least, since it’s going to affect people who currently use data-dependencies or the ledger api.

I’ve been implementing this and it looks like a bigger change than I thought, and wouldn’t be surprised if it broke a lot of existing code. I would be a lot more comfortable with my first proposed solution – to change the default way of translating DAML-LF variants with unit constructors back into DAML types, so that you get a constructor with no argument instead of a constructor with a unit argument. We could even deprecate variant constructor with unit arguments from DAML, since they have dubious utility, like we did for record types whose constructor name doesn’t match the type name (because it doesn’t have a representation at the LF level).

cc @hurryabit

[hurryabit]

I agree with the suggestion to deprecate variant constructors with a single unnamed argument of type (). I would start by showing a warning that explains how you’ll get in trouble when using this with data-dependencies and what to use instead.