thanks for the tip! Yes, locks are on "rare" paths in interpreter, so we won't expect any impact from changes like this. On the other hand, I prefer to follow the recommended practice if it does not make a difference for the code in any other aspect. So
I'll change this to use declarative style.
Slim lock - one of my other disappointments :( I rushed to try it when I found out about it, but... same stuff - it maybe helps with high contention on data, but lock acquisition/release cost is high and the same as old-style lock. So this class wont' help
Making Interpreter production-ready. I hope to round it up in a few weeks. You're right, for now it's just a skeleton, with missing pieces in many places. Here's what on my do-first list:
1. The Binding functionality (LanguageRuntime_Binding.cs) should be completed and extended to support all scenarios.
2. Importing .NET classes/functions into interpreter - for ex, to make Math class's functions directly available in expression evaluator
3. Implement MemberAccess AST node, which implements access to properties/methods of an object like obj.DoStuff(). This is important for scenarios when external object is provided from "outside" and put into Globals (it might be a .NET object or data row),
and script computes a value using columns in a row.
4. I plan to move ExpressionEvaluator to the main Irony assembly to make it available "out-of-the-box" - I realized there are many applications that need a simple expression evaluator with good external integration facilities and extensibility.
I'm rushing to finish all these initial items - expect more soon. Don't start fixing Refal yet, please, there might be changes in interpreter core code. Just investigate and be prepared