Support for integer subexpressions in dimension attribute/statement

[Kurt Smith]

I've just pushed a fix to get the following to parse:

subroutine foo()
integer, dimension(-1:1) :: a
! executable statements
end

Before the base_classes.Variable.analyze() wouldn't work with colons
in the dimension extent list.

The problem remains, though. Consider

subroutine bar(n,m)
integer, intent(in) :: n,m
integer, dimension(n-m:m-n) :: a ! the 'n-m:m-n' expressions won't parse.
...
end

The integer expressions in the dimension(n-m:m-n) are passed on as-is
to the variable's 'dimension' attribute, and
base_classes.Variable.analyze(), when trying to calculate the shape of
the array, fails. The analyze() method assumes the explicit shape
array is made up of explicit integer constants.

The fix, as I see it, would be to parse integer expressions inside the
dimension attribute/statement -- any other possibilities? I'm not
sure how long or how much effort this would take, so I'll push it down
on the priority list.

Kurt

[Pearu Peterson]

Parsing expressions in general needs some work. Currently they are
represented as plain strings. The general plan
is that expressions are represented as symbolic objects that
support basic arithmetic operations in the case of integer, real, and
other numeric expressions.
For that sympycore can be used (this was actually one of the
motivation of starting the sympycore
project) as it can support representing various constructs of
expressions
that are common in programming languages, in particular, Fortran.
So, I suggest that manipulating integer expressions (that are
currently needed
mainly in shape computations) would be supported partially (ie support
most common constructs, similar to what f2py currently supports) until
sympycore features are plugged into the fparser. Then the whole
problem of parsing expressions and manipulating them as needed in
the case of computing array shapes, gets resolved automatically.

Best regards,
Pearu

[Kurt Smith]

Thanks for the explanation. I think I'll be able to get along just
fine with the current state of things, but handling expressions will
be nice in the future -- I'll be happy to pitch in when time allows.

I'm exposing my ignorance here, but how much work would it be to
include full expression parsing inside fparser's current framework, as
compared to the work of plugging in sympycore's support for the same?
sympycore is certainly much more powerful, and it sounds like this is
a pretty definite decision, but is all that power worth the external
dependency? It seems like everything is set up to support expressions
in fparser just with a few more classes and type analysis, etc, but
then again, I know just enough to be dangerous ATM ;-)

Kurt