Motoko's dependency graph leads to dirty candid code

I did dfx build on the motoko-qr by @enzoh and one of the .did files contains the next output:

            type Version_3 = variant {"Version": nat;};
            type Version_2 = Version_3;
            type Version = Version_2;
            type Mode_3 = 
             variant {
               "Alphanumeric": null;
               "EightBit": null;
               "Kanji": null;
               "Numeric": null;
             };
            type Mode_2 = Mode_3;
            type Mode = Mode_2;
            type Matrix_3 = variant {"Matrix": vec vec bool;};
            type Matrix_2 = Matrix_3;
            type Matrix = Matrix_2;
            type ErrorCorrection_3 = 
             variant {
               "H": null;
               "L": null;
               "M": null;
               "Q": null;
             };
            type ErrorCorrection_2 = ErrorCorrection_3;
            type ErrorCorrection = ErrorCorrection_2;
            service : {
              "encode": (Version, ErrorCorrection, Mode, text) -> (opt Matrix);
              "show": (Matrix) -> (text);
            }

It seems that for each level of import indirection motoko generates additional type alias for the imported type (look at Version, Version_2, Version_3). It is not a big issue, however it leads to a difficulties when you try to parse (and interpret) this code with another tools.

Iā€™m using 0.5.7.

3 Likes

This is still a valid candid file, so a general tool should be able to parse and interpret this code. I can probably reduce the type alias for the imported case, but type alias is unavoidable in general. For example, to derive candid types from polymorphic Motoko types, you will have to monomorphize the type definitions, e.g. Result<Int, Text> and Result<Nat, Text> will be given different names in candid.

4 Likes