For example, this function
- Code: Select all
return sin(x * A);
Of course, MorphEngine does not pollute the global state, and the example code above does not refer to global state.
In a MorphEngine calculator, sin() refers to a real-valued "sin" function in the calculator.functions object (which is not simply Math.sin(), but an implementation that a) knows about the current angular mode b) maps periods of pi/2 to exact values of 0 or 1 respectively, instead of relying on inaccurate factory function results), and "A" might refer to a variable "A" in the current folder, or may be an injected constant.
Using the principal tools of function introspection, the "with" operator, and function re-assignment, MorphEngine extends user-written code to "blend" desired objects into the scope chain.
All of calculator.functions, calculator.vars, calculator.vars[calculator.currentDataCategory], and others, are blended in.
This is transparent to the user. If you inspect a function (via "edit" or "visit"), it will always look as you wrote it.
Another instance of code-morphing is natural math entry syntax.
- Code: Select all
f(x) = sin(x)*A
becomes equivalent to the function above through code-morphing.
Code completion and the steps above are employed to realize this.
Code morphing is meant to be theme in this engine and there will be more instances of it being performed.
Obtaining higher performance through code morphing is a goal.
MorphEngine will soon pick up Generators (a JS 1.7 feature) and morph code to make long-running functions interruptible. (This involves invisibly placing "yield" statements into user-written code, and iterating it to completion, instead of simply executing it.)
Use of generators will also permit the engine to call out to the native environment for certain functions (such as compute-intensive matrix operations). This again will be transparent to the user. Code written today, will simply execute faster tomorrow.