Originally Posted by: uni The source code for the function eval():
Thank you for this useful information.
The problem, however, remains unresolved. There are cases when one
must use eval() in a function (like the case I posted
here) because there's no other way to obtain result (in my case it was too large number in the middle of a calculation). In the same time one
must use tools like solve() or w3b5urf3r's NonlinearSolvers (or may like to use your wonderful extension).
So, the question is not
why this is impossible (we kind of already guessed it), but how to change it from current unacceptable state in a satisfactory way.
The problem must not be totally unsolvable. If you use my example above like this:
then if x is undefined before the call, you get the standard "x - not defined" error, but if you define x previously, then the error will say "Variables should be defined for argument-functions" (as a side note, I must say that Russian translation of this text makes more sense - "You cannot pass values inside argument-functions" ). This means that Andrey has means to differentiate cases when a function is passed as argument, and not its value. In this case, if unresolved (throwing "x - not defined" error) eval() inside such function is detected, its processing must be postponed until its invocation, in which place the usual rules should be applied to the eval() called with actual defined parameters. In other words, when preparing
functions, the resulting pseudo-code must still have all unresolved eval()s inherited from its "parents" in the corresponding places, and not preprocessed results of such eval()s.
This would eliminate a lot of frustration and limitations, and allow for much higher usability and intuitivity. SMath will simply be useful, and not just a toy.
Edit:
1. I might guess that the preparation of a function creates a representation where all user-defined functions are expanded, all extension (dll) functions are represented as their entry points and all special functions are processed like in the source code that you provided above. If so, then it would make sense to define yet another dll function "eval" that would take simply SMath-syntax text and act like a "SMath inside SMath". It would be used when the conditions depicted above are met instead of usual processing.
2. The same technique could be used for other special functions that create problems inside argument-functions, like str2num().
3. It is already possible for SMath to correctly process expressions which have some placeholders not filled (consider
time(#) call that in this partial form yields correct results). Thus, it could be useful to allow syntax like this:
k(f(#);5) to work without throwing errors. This would avoid cases when a formal parameter name happens to be previously defined.
Edited by user 23 May 2013 04:24:46(UTC)
| Reason: Not specified