contextual castling

Recall that the current move of a position is the move that reached the position (which is maybe more clearly described as the previous move). Ordinarily the from filter has value equal to the squares from which pieces moved in the current move, and the to filter has value equal to the squares to which pieces moved in the current move. For example, if the current move is white kingside castling, then from will have value of [e1,g1]:

    //last move was white o-o
    from==[e1,h1]
    to==[f1,g1]

Contextual castling refers to the effect of a ―― on a from or to filter within its scope

The scope of a ―― filter

Recall that an ordinary ―― filter can be followed by an optional target filter which is evaluated in the target position of the ―― filter. For instance, to match a position from which White has a rook move that gives check, one can use

    ♖――(check)

A from or to filter inside a target filter is in the scope of the surrounding ―― filter. Thus, each from or to below is in the scope of the containing ―― filter:

    ――(from==h1)
    ――(from==h1 to==f1)

However, if a from or to filter is enclosed in a another filter that could change the current position (like : or find or echo), then the from or to is not in the scope of the ―― filter:

    ――(initialposition:from)

The scope of a ―― constituent

Inside of a ⊢, a ―― constituent has scope consisting of all filters up to the next ―― constituent. Thus, each from or to is in the scope of the preceding ―― in the example below:

    ⊢
     ―― ♕≥2 from==a1 check to==c1

Left and right filters of a ――

Recall that a ―― filter can have left and right filters that restrict the allowed origin squares and destination squares of pieces whose movement the ―― describes:

    ―― // any move
    ♖―― // any ♖ move
    ♖――a2 // any ♖ move to a2

value of from

Suppose a from filter is evaluated inside the scope a ―― filter with left filter Left and right filter Right. Suppose furthermore that when the from filter is evaluated the current move is a castling move, which is to day, that move matched by the ―― filter is castling.

Then the origin square of a moving piece is only included in the returned value if the origin square of the moving piece is in the set described by the left filter of the ―― filter and if the destination square of the moving piece is in the set described by the right filter of the ――.

For example, suppose the move from the current position is a white kingside castling move.

Consider:

    x= ――(from) //x==[h1,e1]
    x= h1――(from) //x==h1
    x= ♖――(from) //x==h1
    x= ――f1(from) //x==h1
    x= ♖――f1(from) //x==h1
    x= ♔―― // x==e1

The same rule holds inside of ⊢:

    ⊢
     ♖―― check x=from //x=h1
     ♔―― x=from //x=e1

The value of from respects any ◎ parameter to ⊢:

    ⊢◎♖
     ―― x=from //x=h1

Value of to

The value of to similarly respects the left and right filters of any ―― of which is is in scope, e.g.

    ⊢
     ♖―― x=to // x=f1

Reason for contextual castling

Previous versions of CQL always treated castling as a move by the moving king and not the moving rook. This convention arose from standard conventions often used in computer-transcribed games. However, the more logical approach is to view the moves of the king and rook symmetrically and to treat both pieces as moving in a castle.

This allows for clearer expression of certain ideas. For example, to find positions where a white rook gives at least 4 checks, use

    ⊢◎♖
      ―― check {4,}

When the focus is on a rook, or when a rook move is required by the ――, it makes sense for only that rook to be considered when castling occurs. This simplifies the logic of some themes:

    ⊢
     ♖―― x=from
       //...computations with x

In practice, this power rarely makes a difference, but it's a logically cleaner and more consistent approach than treating castling as a king move. When rook moves really are needed, the code is much simpler too.