KOFOID@cc.utah.edu (08/31/90)
Dan Winkler's callback routine "evalExpr" is described as doing the
following: "Evaluate[s] a HyperCard expression and return[s] the answer.
The answer is a handle to a zero-terminated string". I find that it also
evaluates local variables within the handler calling the external. This
really isn't surprising, as a a lone variable is the simplest form of an
expression.
What I can't get it to do is to evaluate any expression querying the
number or nature of the parameter list passed into the embracing handler.
Thus, if I have an XFCN, theVal, which evaluates the expression passed to
it as a parameter and then returns its value, the following will not work:
on foo item1,item2 | When called as:
put theVal("item1") | ...
end foo | foo 2, "foobar"
| ...
| it writes garbage.
evalExpr will also not properly evaluate the functions "param(0)",
"param(<any positive number>)", "paramCount()" or "params()".
On the other hand, the following works just fine:
on foo item1,item2 | When called as:
put "dill pickle" into item1 | ...
put theVal("item1") | foo 2, "foobar"
end foo | ...
| it writes "dill pickle"..
What I really want is to tell the external the number of parameters
passed to the handler in which it is embedded. Does anyone have any ideas
how this could be done?
Another, far more difficult question. Can anyone think of a way by which
the XCMD can learn the symbol *name* passed as a parameter to the
handler? That is, given an external similar to the previous examples, and
the following code:
...
put 1438 into appleNum
foo appleNum, bar
...
..is there any way by which theVal can report the symbol name "appleNum"
in addition to its value, 1438?
Shades of self-modifying code! Not to worry: I'm trying to fake
parameter-passing by reference. I have an XCMD which emulates pseudo-var
parameters, but it places inelegant burdens on the programmer.
I want to enable the easy creation of libraries of modular code,
adaptable to a variety of scripting requirements. This can only be done
by avoiding globals. One route is a Lisp-like solution, returning lists
by XFCNs, and parsing them for the required values. The other is the
Pascal-like method of modifying the actual parameter passed when it is
declared modifiable. I have chosen the latter, as it is easier (although
it introduces side-effects).
I would be interested in comments from anybody.
Cheers,
Eric.
__________________________________________________________________
| Eric Kofoid; Dept. Biology, U. of Utah; SLC, UT 84112 |
| (801) 581-3592 |
| kofoid@bioscience.utah.edu |
| |
| -- The University of Utah is blameless for anything I've said -- |
|__________________________________________________________________|