Steve wrote:
I was thinking along the lines of something like:
record graph(ro, phi, sigma,...) ... graph := f(graph) # assignment is redundant in this example! ... # rest of code references graph.ro, graph.phi, etc.
Yes, I see. There are some smaller problems with that but those can be easily solved and even that graph.ro, graph.phi redundancy can be eliminated with OO approach; and f(graph) certainly looks much better than "every ro|phi|sigma| ..." but there is one issue that cannot be solved that way, and it happens if:
f is more general than main(), for example, it might be the function that numerically solves equations and main should be adapted for use with that function, not vice versa. f doesn't need to know for ro, phi ... Moreover, as f is probably not only function that need to be used that way, and there might be others, like g, h, etc. it is not probable that graph can fit all of them.
So, perhaps every x1|x2| ... is still best approach here, and it is actually not that complex (I posted how f could look alike on list, it is in archive, but I never got it mailed), especially because initial "static fr; if /fr|*fr=[]....}" and final "}; return get(fr) " can be safely replaced with $define MULTI_FUNCTION_START and $define MULTI_FUNCTION_END.
You really have my curiousity up! What problem domain are you working in?
Recently I do physical chemistry on my workplace and automated theorem proving for scientific interest. Physical chemistry functions frequently need to return lot of variables, ATP not that much, however, only one is not always the simplest. For phys. chem. I mostly use other tools, rarely Unicon, but for ATP I use it exclusively.
----
Kazimir Majorinc, Zagreb, Croatia
