Support building arbitrary expression (not representing a form)

[kynan]

ExpressionBuilder assumes it builds an expression that represents a form (i.e. is the integrand of an integral on a UFL Form). This restriction is not conceptually necessary and should be lifted. Arbitrary expressions representing a UFL Expr should be supported.

A current limitation are index constructors bound to FormBackend, see #50.

[gmarkall]

So do you agree that the index constructors for basis indices should take a count and an element? Or is this still too restrictive for what you want to do? My rationale behind passing it an element as opposed to an argument is that coefficients might need a basis index, and they have an element but not an argument, and arguments also have an element. The element contains enough info to work out the upper bound for the index.

[gmarkall]

Just seen your comment on issue 50 - I'll continue the discussion in that issue since its more relevant there than here.

[gmarkall]

So, after fixing Issue 50, the only reason that ExpressionBuilder holds a reference to the FormBackend is to get the number of Gauss points from it. We could completely break the dependence of ExpressionBuilder of having a FormBackend if we passed the number of Gauss points to the constructor of the ExpressionBuilder instead.

Any thoughts @kynan ?

[kynan]

No objections, that seems a very reasonable thing to do.

[gmarkall]

This issue was fixed in the generate-transforms-experimental branch before it was merged (dfc0aa469f). It turned out that the ExpressionBuilder never needed to know the number of Gauss points (and therefore had no dependency on a FormBackend anymore) because it didn't need to generate linearised array subscripts, which would have contained a multiplication by the number of Gauss points.