libasr: Add C backend Codegeneration using --show-c

[Smit-create]

#393

[certik]

Thanks for the PR. Isn't most of the C backend almost identical to the C++ backend? As mentioned in #393, I would prefer to have just one file, say asr_to_cpp.cpp, and in there have some flags to determine the kind of output. It seems to me it should be doable, because:

• We want to be able to configure how exactly the C++ is generated, things like:
  • arrays (C style, Kokkos, XTensor, ...)
  • strings (C style, std::string)
  • list (std::vector, our custom C approach)
• C that we would generate is a subset of C++, it seems it's effectively just one of the options above, and we have to have such options anyway

I think we just have to decide how types are being translated, and we have to support multiple C++ implementations of arrays, so we just add a C version.

The general syntax for functions, expressions, etc. is I think almost the same.

[Smit-create]

Yeah, that's true. Maybe we can add a class called ASRtoC and ASRtoCPP as the child class of ASRtoC which will add/override the methods of its parent class?

[certik]

I thought about the base/sub class approach, but it seems that while some methods might be shared, a lot of them will have just slight differences. We could use the base class for common functionality in regular methods, and the subclass implements the actual visitors. But I suspect the easiest is to have just one class, that has options in it to specify how the generated code should look like.

[certik]

This is probably fine. We will then create a common base visitor and put all the identical visitor functions as well as any other common code that is shared with the C++ backend in there. This approach allows us to work on the two backends separately, and keep the code reasonably simple. And we can always add methods to the base class that internally dispatch on C/C++, if that is easier. So it seems this is the best of all approaches.

[certik]

Simplified in #517.