Verify

Interpreter

The Verify interpreter should be fast to execute. If I have to import 20 thousand rows for unvalidated data from a customer, I do not wish for it to do the equivalent of a fork every time for every line. The Verify language should be parsed and the parse tree stored in memory. Access to things that change should be in turn, generic and easy. Fast to execute, fast to develop in.

The interpreter should be pluggable. It can be assumed that BASIC has features that Verify’s interpreter cannot do as quickly. Or it may wish to be plugged into other systems as well. For this reason, all functions are written BASIC. Floating point precision libraries are another example of something that may be required to be plugged in, as there are several, not completely agreeing floating point systems out there. You may wish your entire company to standardize on one. A set of plug-ins should be configured and plugged in once for many uses.

The Verify interpreter should be easily bridgeable to and from another system. It should be simple, and or similar as:

My $interpreter = Verify->new( );
$interpreter->pluggedFunctions( { "zero" => { $_[0] * 0 } } );
$interpreter->compile("/beer/something.vfy");

My %bind_variables = get_variables_from_tk_interface_put_into_hash( $t
+k1 );
if  $interpreter( \%bind_variables ) ne "YAY" die("EEK!");

My %bind_variables = get_variables_from_tk_interface_put_into_hash( $t
+k2 );
if  $interpreter( \%bind_variables ) ne "YAY" die("EEK MORE!!");
[download]

The interpreter requires a mathematical handler be used. The default supports +,-, <=, <, >, >= and the identity function for assignment. An enahnced default one would include / and * for use with BASIC's internal floating point representation. The default would throw an error should / or * be used. The purpose is because there are various floating point operation libraries in use. Many people are comfortable in BASIC's implementation, where as someone like NASA may wish to use the NASA standard one, should there be one.

Verify Language description

The Verify language is intended to be very, /very/, simple. It is for data validation, not to do fractals, reformatting of XML or anything really interesting besides validating data. It is of the same ilk of a template language or SQL language. It should not promote being used for things outside of its scope.

Features not included are

• variable scope within a single execution, within the language.
• type safety
• complex data structures beyond arrays.
• exceptions
• built in functions beyond simple algebra and boolean operations

The 4 basic mathematical functions are supported, + - / *. Mathematical operations,all of them, are pluggable. The results are user-defined numerical.

The atom: a single value will be typecast accordingly. "1" gets cast to a numeric one in numeric operations, while 1 gets typecast to a string in string comparisons. The numerical castings are done via the floating point implementation used for consistency.

Binary (and trinary) use of the numeric comparison operators, < <= > >=. They can only be used on arithmetic operations. The purpose is to make it easy to do a "between" easily, i.e. 1 < x < 5. i.e. 1 + 2 < 5 + 6. The result of these operations are boolean.

Equality, to be used between numbers and strings as one would expect. "1" == 1 would be true per the casting of an atom. The resuls of these operations are boolean.

Regular expressions are supported, in the form of perl syntax, i.e. x=~/abc/, x!~/abc/. The result is a boolean.

The raw booleans, true and false are available.

Boolean algebraic operations of "or" and "and". To be used on boolean operations.

The various built in Verify language abilities of if-else, while and for are the same as the C languages syntax, including the use of block usage with braces. Return is supported to dictate levels of success or error.

Variables do not need declaration, similar to perl without using strict. They default to 0. The same is true of arrays. Referring to an array without an index refers to the first element. Array sizes do not need to be declared. They follow basic C naming rules.

Special variables, called bind variables, act exactly the same as variables, except they must be prefixed with a colon. Their values are passed in on execution of an interpretere, similar to how SQL systems work, very similar to DBI. This allows for simple syntax of, if( 1 <= :x < =10 )

"Plugged" functions are referred to as one would call a function in C. The state of all internal variables is accessible and modifiable. Use with care.

Example

A year or two ago, I worked w/ a system that directly imported data into a DB, no validation. Unfortunately, the spreadsheet was done by hand, no validation. An example of what I might have used for a validation example would be:

If( :company == "" or :stock == "" or :sku == 0 )
    Return "E_ROW_INVALID";
if( checkSalesPerson( :salesperson )  == false )
    return "E_INVALID_SALESPERSON";
[download]

The checkSalesPerson plugged in function may contact a database, or be preconfigured w/ a list of valid sales persons. Or it could have been done as:

if( :salesperson != "gsmith" and :salesperson != "rjohnson" )
    Return "E_INVALID_SALESPERSON".
[download]

If someone wrote a plugged function to check for a person being in an array, one could write something like:

Sp[0] = "gsmith";
Sp[1] = "rsmith";

if( inArray( :salesperson, sp ) == false )
    Return "E_INVALID_SALESPERSON".
[download]

Many plugged functions will be included as example and to be used in day to day operation.