On Wed, Nov 13, 2013 at 1:09 PM, F. B. <[email protected]> wrote: > > Yet another alternative approach: > > Instead of defining Add and Mul as dependent on a parametric type associated > with the properties of the expression, just do the opposite. > > Examples (Julia-like syntax, {T} is the parametric type, <: means > inheritance): > > type Expr{T} <: Basic > type NonCommutativeExpr{T} <: Expr{T} > type InfinitiesExpr{T} <: Expr{T} > type MatrixExpr{T} <: Expr{T} > type NonCommutativeInfinitiesExpr{T} <: Expr{T} # or better use multiple > inheritance? > > Now, their corresponding Add, Mul, Pow classes are given by > > NonCommutativeExpr{Add} > NonCommutativeExpr{Mul} > MatrixExpr{Add} # instead of MatAdd > MatrixExpr{Mul} # instead of MatMul > > and so on. > > This has the advantage to require developers to subclass the expression only > once, while the corresponding Add, Mul, ... objects are automatically > created by parametric typing. There is no covariance-invariance problem for > the parametric type, because it is not using the template, it's using the > main type in the dispatch, so this is compatible with lots of other > programming languages.
I wonder how difficult would be to write just a very simple core in Julia, just so that we can experiment with this. See how extensible it is, and so on. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
