Re: Retaining Backwards Compatibility in a Changing World
Posted: Fri Mar 13, 2015 8:44 am
@mwieder: The current parser can certainly be made to flag syntax which might be affected by changes, but things like type inference and data-flow analysis would be needed to advise about other changes (string <-> empty array conversions, for example). We are going to be re-hosting the current scripting language on the LCB VM at some point down the line which might open up greater opportunity here as there is (in that design) only one place where type-conversions and action executions occur. (The current LCS implementation uses hand-crafted C++ to type-check each argument of each piece of syntax and then dispatch it - thus meaning all that C++ code would have to be instrumented in order to offer any sort of analysis mode).
One option would be to have a run mode where the VM accumulates 'new execution mode' violations against lines of script. i.e. As the scripts run, and the VM notices things that are fine with compatibility mode on, but would not be with it off and logs them:
The implicit array <-> empty string conversion occurs at passing pString to 'combine', so it would be possible at the point the VM does the type-conversion to annotate that line with something along the lines of 'Warning: <array> argument of 'combine' forced converted from string to empty-array'. Realistically, due to the dynamic nature of LCS static analysis of this kind of thing can only go so far - so, the only way to 'find' all places which might cause problems would be through execution and inspection.
One option would be to have a run mode where the VM accumulates 'new execution mode' violations against lines of script. i.e. As the scripts run, and the VM notices things that are fine with compatibility mode on, but would not be with it off and logs them:
Code: Select all
on doBadThings pString
combine pString with ","
end doBadThings