Typeclass/Type Synonym multi project error

Hello, I’m working on something that requires 2 different daml projects to to exist, with one as a dependency of the other, I shall call them project A and B.
Project A is a dependency of B, and on it I have a function that attempts to interact in a more generic way with templates. For this I have to specify all of the Typeclasses that a template belongs to, so I can perform the action I require. As part of the native code base, I saw there is a type synonym that encompasses all of the afore mentioned template typeclasses. So opting by using that synonym, I built project A and used it for project B.
Now to the problem. By using the type synonym I now get the following error on project B, when trying to use the function constructed on A.

error type checking value Tests.Bar.BarTests.testBar:
  type mismatch:
  * expected type:
      <s_1 :
         <m_signatory :
            Unit -> Main.Foo.Bar:Bar -> List Party>;
       s_2 :
         <m_observer :
            Unit -> Main.Foo.Bar:Bar -> List Party>;
       s_3 :
         <m_ensure : Unit -> Main.Foo.Bar:Bar -> Bool>;
       s_4 :
         <m_agreement :
            Unit -> Main.Foo.Bar:Bar -> Text>;
       s_5 :
         <m_create :
            Unit -> Main.Foo.Bar:Bar -> Update (ContractId Main.Foo.Bar:Bar)>;
       s_6 :
         <m_fetch :
            Unit -> ContractId Main.Foo.Bar:Bar -> Update Main.Foo.Bar:Bar>;
       s_7 :
         <m_archive :
            Unit -> ContractId Main.Foo.Bar:Bar -> Update Unit>;
       s_8 :
         <m__templateTypeRep :
            Unit -> (forall (proxy : * -> *). proxy Main.Foo.Bar:Bar -> TypeRep)>;
       s_9 :
         <m__toAnyTemplate :
            Unit -> Main.Foo.Bar:Bar -> Any>;
       s_10 :
         <m__fromAnyTemplate :
            Unit -> Any -> Optional Main.Foo.Bar:Bar>>
  * found type:
      <m_signatory :
         Unit -> Main.Foo.Bar:Bar -> List Party>
  * expression:
      Main.Foo.Bar:$fHasSignatoryBarDAML-LF typechecker

I would like to understand, if this is something that is intentional, and if so, that would mean the only way around it is to write all of the typeclasses that are needed for the function, right?
Thank you

1 Like

Hi @David_Martins! This sounds like an instance of this issue, where constraint synonyms were not correctly handled in data-dependencies: Data-dependencies do not preserve constraint tuple constraints. · Issue #9663 · digital-asset/daml · GitHub

This issue should be fixed in the latest versions of the daml SDK (1.14.0). Could you try upgrading B (by setting sdk-version: 1.14.0 in daml.yaml) and recompiling?

7 Likes

Indeed, by updating both projects to sdk version 1.14.0, this issue ceases to exist.
Thank you.

3 Likes