0
votes

Introduction

Pinescript is a propriety programming language for backtesting trading algorithms. The language has always been interesting to me because it is orientated around series which as a result certain features works in a way that differs from normal languages.

The four main series variables, open, high, low and close point to arrays that form bar data, so if you were to write the code

plot(close)

It would plot the close prices on the graph. That's easy enough to understand as under the hood the variable close is just pointing to a array of float price data and the plot method is plotting out that array.

Similarly the code

plotchar(close > open, 'A')

Will plot the character 'A' where the close value is greater than the open value in the arrays.

If statements work in unique ways when a comparison of two series take place:

1.

if (close > open)
     strategy.entry(id="EL", long=true, qty=5)

Which is equivalent to

2.

strategy.entry(id="EL", when = close > open, long=true, qty=5)

In example 1, the if statement results are applied to all the arguments of the strategy.entry method ( wherever any series is referenced as long as it's in that if statement scope). They key parameter in this case is the when parameter. When not defined the when parameter points to an array full of true values. However since its inside a scope where series values can only be evaluated where close > open, the result is that it works in exactly the same way as example 2.

The example above is not directly relevant to my question, but I kept it in to emphasise how Pinescript works in different ways to what might be expected in a traditional programming language.

Dynamic data

The part that I do not understand is when certain special variables get mixed into normal expressions. These variable's data do not exist until certain functions are called, however they appear to be evaluated as one would intuitively expect regardless of the fact that their data cannot exist at the time of the parser reading the input code. For example the series variable strategy.position_size is a series variable (of floats) that contains the overall position size as the orders are evaluated. E.g.

strategy.entry(id="EL", when = close > open, long=true, qty=5)
plot(strategy.position_size)

This will plot out the position size on the chart. This is simple enough, except that the below code will also yield the same results:

plot(strategy.position_size)
strategy.entry(id="EL", when = close > open, long=true, qty=5)

This suggests that the positon_size variable is treated as some kind of special variable that will not be evaluated till any of the order functions (strategy.entry) are executed. Maybe the compiler will detect that the line of code plot(strategy.position_size) cannot be evaluated at that point so is saved till after any code that affects this variable (strategy.entry) is ran.

However the bit where it gets confusing is the fact that you can use these special variables within expressions that would directly effect the result of that variable. For example:

strategy.entry(id="EL", when = strategy.position_size==0, long=true, qty=5)

When the compiler reaches the strategy.entry method, it see's that it should only enter a position if position_size == 0. However the position_size variable data is directly dependent on when strategy.entry is called. This seems like a catch 22 scenario and I am unsure as to how the compiler would handle this code.

Do you have any idea how the Pinescript compiler handles these special "dynamic" variables? Are there any documented examples of a scenario like this occurring in different programming languages?

Apologies if my terminology is not on point or confusing. I've been getting into interpreter design for only a year now and I still have a lot to learn.

1

1 Answers

0
votes

There is no magic here. You need to understand that strategy.entry / exit / etc will only PLACE the order, and the order will be executed later and only after that the position will open or close and the value of strategy.position_size will change.