Initial implementation of Symbolic type

[Thirumalai-Shaktivel]

cc @anutosh491

[Thirumalai-Shaktivel]

Currently, this doesn't work in CPython. I think we have to handle this in ltypes and make sure this works with CPython

[certik]

from lpython import Symbolic
from sympy import Symbol
...

Suggested change

	x: symbolic = Symbolic('x')
	x: Symbolic = Symbol('x')

[certik]

Here is a simple symbolic code:

from lpython import S
from sympy import Symbol

def f():
    x: S = Symbol("x")
    y: S = Symbol("y")
    z: S = x + y
    print(z)

f()

At the ASR level this would be represented using IntrinsicFunction, we have to add Symbol and SymbolicAdd to it. Print has to be extended to accept a Symbolic expr.

Then I would write an ASR pass that transforms the above into explicit calls to SymEngine's C interface, so something like (approximately):

basic x = symbol("x')
basic y = symbol("y")
basic z = add(x, y)
printf(str(z))
free(z)
free(x)
free(y)

where symbol and add and str are C functions implemented by SymEngine, basic is also implemented there. Here is an example: https://github.com/symengine/symengine/blob/2b575b9be9bb499d866dc3e411e6368ca0d1bb42/symengine/tests/cwrapper/test_cwrapper.c#L19.

Let's use the LLVM backend, which will generate an object file, that depends on these C functions. Then when we link, we have to link against the SymEngine library (either static or dynamic) and ensure the C++ runtime library (that SymEngine depends on) is also properly linked. It shouldn't be difficult, and we should only do it if Symbolic is used, otherwise we should use our current approach which does not depend on SymEngine.

I made a dedicated issue with the design here: #1607.

[anutosh491]

Closing as the SymbolicExpression ttype was correctly implemented through #1846 .