Can we guarantee that the TYPE_ID numbers will not change?

[certik]

We want to be able to quickly compare types in LPython, see lcompilers/lpython#2351. The fastest way that we were able to find is to just compare the TYPE_ID integers directly. I think this is the best solution, the only caveat is that if SymEngine changes the order, then older LPython with newer SymEngine will break.

One solution is that if we need to change the order, we'll make a major release. Otherwise in minor or patch releases we will not change this order.

[isuruf]

No, you shouldn't rely on that. In C, you can use basic_get_class_id('Integer') to get this value once. Since this needs to be done only once, it should not affect runtime.

[certik]

Is the idea that at the beginning of the program, we run this for all names like Integer, save it to some variables, say ID_INTEGER: i32 = basic_get_class_id('Integer') and so on, and from then on, we just use ID_INTEGER, so there is no overhead in the actual code that needs to check for the types?

[isuruf]

Yes. That's what the Julia wrappers do.

[certik]

@anutosh491 see above how to do this. So continue with your current approach of using a variable for the ID, first hardwire it, and later we'll initialize it using basic_get_class_id at the beginning of the program. We need a mechanism for this from an ASR pass anyway, as almost all such backends like OpenMP or CUDA typically require some initialization code at the beginning of the program.

Thanks @isuruf !

[anutosh491]

Sure as of now we would only need 5 classes (Pow, Mul, Add, Log, Exp). So let's just use the enumeration values of these classes as of now and once we start expanding further and handling more class, I'll introduce a map/enumeration through basic_get_class_id
Thanks @certik @isuruf