Closed rupertford closed 5 years ago
Looks like this is as simple as changing one number in https://github.com/stfc/fparser/blob/0.0.8/src/fparser/two/utils.py#L620.
In the work that I've done with path based querying for things like a UML generator, I've got an interface to stuff like for actual_arg in node.find_decendants('Actual_Arg'): ...
. In that situation, it is transparent to the user whether there was a list or not. Given this, I could see an argument against making all list-able things be lists even if they are length 1. I personally don't have a preference either way.
Created branch 170_single_object_lists
fparser2 generates a list class whenever there is a Fortran rule that specifies a list. In the current implementation a list object is only created if there are two or more items in the list. If there is only one item then the item itself is returned, rather than a list containing the item.
As an example, consider the Fortran2003 rule for a calling a subroutine and its arguments ...
If there are two arguments then we will get the following hierarchy
but if there is only one we will get
There is nothing wrong with this is terms of correctness. The problem comes when trying to traverse the parse tree. If you want to get access to all Arguments then you need to add in extra code to deal with the case when there is only one.
This is the situation for all generated lists in fparser2 and there are many of them (just search for *-list in the spec).
The proposed solution is to have a list object created when there are 1 or more items in the list. I don't think there is any fundamental reason why this can't be done in fparser2 and on face value it seems quite a simple change but it would nee to be investigated.
This would mean a change to the generated fparser2 parse tree which would affect anyone who has written code that relies on the current structure but I think it is worth it.