On Wed, 2003-10-22 at 02:32, Majorinc, Kazimir wrote:
> >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.
Hmmm, if f doesn't need to know about ro, phi, etc, how can you rely on
the side effects as you do? And there's no need for f(graph) to know
much about graph, since records are subscriptable:
procedure f(x)
x[1] := "Hey"
x[2] := ","
...
return x
end
Naturally, you have to know some things, such as the expected size of
structure x, but that's equivalent to knowing the number of parameters
in the other approach. (In fact, the above approach is extremely
general, since it takes lists as well as structures.)
> 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.
This is still scary code to me! Written with the reliance on
the static variable fr means that you have to be *very* careful about
how it's called, which means the calling procedure (main) has to
understand quite a bit about the internals of f. For example, if in
one place in your code you only want the first two 'side effects', you
cannot write:
every x1|x2 := f(x1,x2,x3,...,x10)
without causing truly magical behavior from that point on (i.e.
difficult to debug...)
> >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.
Interesting work! It still 'feels' to me that the single variables
actually are groupable into sets of related variables and hence amenable
for representation as a structured type (or class, as Clint suggests).
The field I'm working in (astronomical telescope control) has similar
characteristics - the 'pointing model' used to keep the telescope on
target as everything around it spins requires 15 or more parameters that
are functionally related. In the old FORTRAN code, this meant functions
with 15 or more call by reference parameters, but if you looked at the
entire program it obvious that virtual all functions shared the same
set of parameters (not necessarily all of them, but some subset in any
event). In C and Java [and Unicon] it was simpler (and produced a
cleaner 'main') to put those parameters into a single structure that was
passed around (and returned). [In some cases, the 'single' structure is
actually a hierarchy of several substructures, when the implementation
seemed to fit that model better (e.g. some variables were related to
environmental effects (air temperature, wind speed and direction, etc)
while others had to to with astrometry [rotation of earth, position of
moon, time, etc), but it was always cleaner to group related
variables into structured types.]
In the end, though, you have to happy with your approach.
--
Steve Wampler <[EMAIL PROTECTED]>
-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
