...

This one line instructs the OpenInsight compiler to pass your program to SRP_PreCompiler before passing it on the standard BASIC+ compiler, given the SRP PreCompiler to ability to trans-compile new language features into fully supported ones. These new features are documented here.:

• For Each Loops
• Conditional Return Statement
• Service Modules
• Event Modules
• Unit Test Modules
• Unpacking

Extended BASIC+ Syntax

For Each Loops

For each loops offer a convenient way to walk through a dynamic array from beginning to end. If you have an @FM delimited array, you can do this:

...

For Each Value in MyValues using @STM setting Pos
    NewValues<Pos> = Value
Next Value

Anchor
return return

Conditional Return Statement

...

Note that this syntax should only be used for the stored procedure's final Return statement, not for returning from a gosub.

Service Modules

SRP has been a big advocate for organizing code into Service Modules: stored procedures in which the first parameter identifies a service to execute. Normally, this involves branching to gosubs, mapping the input variables, and making sure the stored procedure has enough parameters to cover all the services' needs. Here is a traditional example:

...

Again, this has no effect on how your code functions, but if you are in the SRP Editor, those options will appear in a drop down as you type.

Event Modules

Commuter modules have been around for some time, and they are structured very similarly to services. Typically, gosubs are created for each event, and a large case statement uses the current control and event to branch to the correct handler. Here is a typical example:

...

Moreover, the SRP Editor will autofill the event's parameters, saving you valuable time.

Anchor
unittest unittest

Unit Test Modules

Unit Test Modules are stored procedures containing multiple related tests.

...

This statement is key to making unit tests work. When the evaluation fails, the SRP Editor will display the two values side by side for easy comparison.

Unpacking

IMPORTANT: Unpacking was added in 2.1.1 and is not supported in prior versions.

Unpacking lets you assign elements of a dynamic array into variables all on a single line! For example, if you use the SRP_Date Decode service, you'll get an @FM delimited array of information. If you wanted to pull the year, month, and day, you would traditionally need to do this:

Info = SRP_Date("Decode", SRP_Date("Today", 1))
Year = Info<1>
Month = Info<2>
Day = Info<3>

With unpacking, you can do this:

(Year, Month, Day) = SRP_Date("Decode", SRP_Date("Today", 1))

The unpacking syntax is activated when you surround your variables in parenthesis. Order matters. The first variable gets item <1>, the second gets item <2>, and so on. You can skip a position using the NULL keyword, an underscore, or just omitting. For example, if you wanted year and day, but not the month, any of these three formats will work:

(Year, NULL, Day) = SRP_Date("Decode", SRP_Date("Today", 1))
(Year, _, Day) = SRP_Date("Decode", SRP_Date("Today", 1))
(Year,,Day) = SRP_Date("Decode", SRP_Date("Today", 1))

If you need to unpack an array with a delimiter that is not @FM, then you add the USING keyword after the parenthesis:

(First, _, Last) using ',' = "John,Seymour,Doe"

This syntax is useful for smaller arrays when readability is important to you. This is not useful for parsing large records. You can only unpack into individual variables, not into other arrays or matrices.

Caveats

The SRP PreCompiler will work in any BASIC+ editor, but there is an important caveat to using Enhanced BASIC+ in anything other than the SRP Editor. The SRP Editor recognizes the new syntax and highlights code accordingly whereas the builtin OI Editor will not. Everything will still compile and run, but it will a little harder to read. Moreover, some features of the PreCompiler, such as the metadata, won't impede your code, but you also won't get the most out of your development outside of the SRP Editor.

...