Visual FreePro introduces the concept of the cask. A cask is a discrete entity which can appear anywhere in an expression.

Consider:

k = foo()

In this code there are technically 7 parts:
(1) "k"
(2) whitespace
(3) equal sign
(4) whitespace
(5) "foo"
(6) open parenthesis
(7) close parenthesis

Were I to introduce other items into the midst of this it would cause a syntax error, unless they are appropriate, as in "k = 3 + foo(1)" and the return result of foo() was numeric.

The cask was created to allow the injection of items at any point horizontally across an instruction. It is constructed in three basic components: left side, middle, right side. These represent the cask identifier, name, and cask identifier.

I have defined three basic types of casks, and they are of the syntax form:

(1)  (|reference|)
(2)  [|definition|]
(3)  <|flow|>

A cask can be embedded within a command without affecting the otherwise standard syntax.

Consider:

k = (|NSI|) foo()

This injects the (|NSI|) cask into the middle of the "k = foo()" source code. In this code there are now 8 parts:
(1) "k"
(2) whitespace
(3) equal sign
(4) whitespace
(5) "NSI" reference cask
(6) "foo"
(7) open parenthesis
(8) close parenthesis

VXB++ defines the (|NSI|) cask as something called a "no step into" cask, which means were I stepping through this code with F8, I would explicitly not go into the foo() function even though I am stepping into with F8. This would be of use had I already debugged the foo() function, for example, but not yet debugged the foo2() function, as in this example:

k = foo2(foo())

Without using the (|NSI|) cask, when I pressed F8 I would have to always go into foo(), come out, and then go into foo2(). Or, I could encode the results of t = foo() on a line above and the use t instead of foo() for the input into foo2(), but this would require me remembering to use F6 on that line, and not F8.

By injecting the (|NSI|) cask into the source code, all of that is avoided. I can simply control where I go by using the form:

k = foo2( (|NSI|) foo())

This code block would tell the debugger not to step into foo(), but to go ahead and step into foo2().

It may look confusing in raw text form, but the Visual FreePro IDE adds syntax highlighting features which make it stand out and be easily identified.

There are also other standard functions created with other casks, such as the (|IFP|) cask, which allows in-flight parameters to be referenced in a subsequent part of the expression. Consider:

k = foo2(foo())

In this form the return result of foo() is used as input into foo2(), and the return result of foo2() is used as input into the equal assignment into k. In standard syntax forms there is no direct way to access the return value from foo() without rewriting the expression to be on a prior source code line. However, were I to use this foo2(foo()) code as the test in a DO WHILE block, then it would be lost without adding it twice (once before the DO WHILE, and once at the end before the ENDDO).

Consider:

lnFooReturnResult = foo()
DO WHILE lnFooReturnResult * foo2(lnFooReturnResult) > 5
    * Other code goes here
    .
    .
    * Update our foo expression
    lnFooReturnResult = foo()
ENDDO

VXB++ defines the ability to access these "in-flight parameters" through the (|IFP|) cask.  Consider:
<pre>k = lnFooReturnValue * foo2( (|IFP|lnFooReturnValue||) foo())

This would assign the foo() return result to a temporary variable visible only on that source code line, called lnFooReturnResult, for the purpose of use throughout the rest of the source code line.

Note that Visual FreePro also allows this to be made into a permanent form using the syntax:

LOCAL lnFooReturnValue
k = lnFooReturnValue * foo2(lnFooReturnValue = foo())

In this example, a literal assignment is made in the middle of the command.

Again, it might all seem and look confusing at first or in raw source code form, but these forms allow the return result from a sub-expression to be stored either into an in-flight variable, or to a permanent variable, which can then be used at other points in the expression, such as in the multiplication operation shown here.

Note also that I am considering making these variables sticky, such that even in-light parameter variables could be referenced later in later source code lines as well, after having initially been populated at some point.

And there are more uses which will be revealed over time, such as in Visual FreePro 2.0 and the Journey database engine, the use of these casks will become a very large, fully front-facing feature of Visual FreePro.

-----
For now, it is enough to inject this concept into your thinking:

"Casks represent a tool to insert keywords into an otherwise syntactically correct programming expression, the purpose of which is to convey or access compile-time and/or run-time information that makes better use of available information, and can help one be a better developer."

Please ask any questions.