Many of the posts in this forum are of the type: "How do I program <<indicator XYZ>> in CFL?" One of the Worden trainers then helpfully posts a 40-line CFL script to compute the indicator. That's great, but many of the indicators have relatively simple formulas, and yet they expand into this huge formula. Typically, it's a tortured mess of redundancy, computing intermediate results over and over again, with oodles and oodles of parenthesis wrapping complex sub-formulas, and computing data points for each bar going back in time individually.

Most of this is caused by two facts:

1. CFL doesn't have variables. You can't compute something once, stuff it in a variable, and then use it multiple times thereafter to simplify the formula. A CLF is literally a single formula with no sub-steps allowed. If you need to reference a complex calculation 27 times in your CFL, you'll need to type it 27 times.

2. CFL doesn't have loops. This makes CFL extremely painful when you want to compute something over a range of historical bars. While AVG, MIN, and MAX work over time, they all reduce to scalar values. For instance, there's no way to convert a range of closing prices to a log scale except by computing LOG on each closing price (e.g., LOG(C1), LOG(C2), LOG(C3)...). That's painful.

It seems like CLF has been kept simple on purpose. I assume that's because it's computed on the server side and a simple language without loops is quick to execute and doesn't risk infinite looping.

If that's true, I'm wondering if #1 could be solved. It seems like it would actually reduce server computation time to eliminate redundancies by computing intermediate results once and then reusing them throughout the remainder of the CFL.

Also, I'm wondering if array operators, similar to what Amibroker uses, could help eliminate the needless loop unrolling that goes on today. Those would be bounded and would not loop.

Does Worden have any thoughts about implementing something like this?? Honestly, every time I approach writing a CFL for even a simple indicator, I get queasy because I know it's going to expand into a huge amount of "goop" that is difficult to understand and debug.

I would love it if the Personal Criteria Formula Language were more flexible in many of the exact ways you are describing. Thank you for your suggestion.

Yes, Bruce, it seems like you're the primary victim in this tragedy. I see all the helpful answers you post when people can't figure out how to write the CFL. I constantly think to myself, "Bruce knows what he's doing, so that's probably as near-optimal as you can get, but wow, that's painful."

Sad that this question has been here for a couple weeks now with no official response from Worden. TC2000 has been a great tool for me, but I'm increasingly running up againt the limitations of CFL. While I can sometimes do what I want, the pain is outweighing the gain.

Your suggestion was submitted to development, but I do not know when or if any particular suggestion might be implemented. This particular suggestion would not be a simple change to make to the program.

I will mention that we did release a product in the past (which is still available but no longer in development) called StockFinder which does have a full programming language built in called RealCode (based on Visual Basic).

RealCode™ Reference PDF
RealCode™ API
RealCode for Real People: Indicators (6:05)
Writing Conditions in RealCode (10:11)