Verify

You said:

Variables do not need declaration, similar to perl without using strict. They default to 0.

p.s. Your perl pseudocode is off. "my" is written in all lowercase, and

$interpreter( \%bind_variables )
[download]

$interpreter->( \%bind_variables )
[download]

I've thought about adding a builtin called "defined" or "isnull" that will check if a bind variable, or internal is null. I don't want to get in the mess of passing nulls around unless there's good reason. A real life valid example if it were to actually allow the assignment vs the comparison of undefs...

I'll fix my psuedocode tomorrow. I did it in word. Stupid grammar checker. :)

Hmm I don't seem to have made my position clear. What I mean was, occasionally in data, an empty string and NULL are equivalent. Occasionally, 0 and NULL, or 0 and "" are equivalent. Effectively testing this in Perl is a bit of a pain, and in SQL it's even a lot worse because

SELECT * FROM mytable WHERE foo=foo
[download]

will not show the records where foo is null. Purists might say this is how it should be, but I think it's just not very practical.

It'd be nice if you provided a simple means to test if a value is, say, NULL, 0 or "", perhaps using something like in (as in Mysql):

if($foo in (0, "", undef)) ...
[download]

I'm actually not even sure that NULL is a valid value for the IN list in Mysql...

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

if( ! inArray( $salesperson, \@Sp ) ) {
    return E_INVALID_SALESPERSON;
}
[download]

In the world of systems, you ahve two extremes, high abstraction of duty, and none. Then there's the inbetween. I looked at the problem from the php perspective. php is a templating language that you can code in. So you wind up with 3500 core functions and the ability to put anything anywhere.

So back to your example. If I had no framework, I could create a module and various objects that work as validators on other objects. That would be a new framework, true. But it falls into the trap of being a validation language I can write code in. For this very reason, I'm not fond of many template languages and similar which allow raw code to be executed. Why would I ever wish to use DBI from this to validate my data as being of certain standards?

So for instance, sigil's are gone in my language for data types, since a scalar in perl terms is just a 1 element array in my language, where you just don't use the index. You have trinary compares for < and > for easy betweens. You have variables taht refer to the outter world as :someVar.

To put it in the frame of mind of an architecture. What I would do in the past, is use something like HTML::Template and CGI. I would take in all my inputs, create an object tree of things like User, Group, Message, Topic, Node, populate them with my data, and call various functions to validate each object in the object tree. Each object would be validated in the native language and returned.

But I run into a similar problem of replacing HTML::Template w/ here-docs. Yes, I can perform invalid syntax in either, and accomplish the same in either, but the here-doc method can be very powerful. Almost TOO powerful. If I'm smart and good and all, I can accomplish a pristine system w/ no issues of what is doing what. If I'm bad and/or not as smart, I can start doing DBI calls in places I'll be rendering templates. That scares me. It's the same issue of actually using php as your template language, or JSP as a coding language.

Heh, imagine if you wrote DB queries in perl instead of SQL.

The advantage I propose, is the same as HTML::Template, Class::DBI and Catalyst. I can have clear seperations of duty, that are done very well, and won't comingle. The template language only makes stuff well formated, where Class::DBI takes objects and stores/retrieves them for me, where as catalyst deals w/ URIs, what is called and the clear seperation of one thing from the next. With verify, I can start out w/ nothing, and fill in the validation w/o worrying about stepping on things like Class::DBI or HTML::Template.

BTW, mind you, I never said the underlying language /was/ perl, but even if it was, it is a very simple subset.

The thing is that your proposed language is almost raw code. ;-)

I think that splitting everything up in different layers of abstraction is the way to go. I wasn't criticizing the concept.

This is completely subjective, but I tend to dislike mini-languages. E.g. although I use Template Toolkit, I'd be much happier if it used a slightly modified Perl (which the only major difference would be the removal of curly braces) instead of its own language. I even considered using Template::PSP but it really doesn't have all the features I need.

Going back to the specific example you gave, Class::DBI and Catalyst are substantially different from hand-written SQL and plain CGI coding. While your proposed language is not.

If I were to implement a verification language, the "code" would probably be some sort of subset of YAML (not because it would ease parsing, but because I really like YAML) and look something like this:

# type checking
parameters:
  # + concatenates rules, pad does smart padding
  flight_number:  char(2) + pad(integer(0 .. 9999))
  flight_type:    char(1)
  # variable passed as a parameter to the template
  total_seats:    integer(0 .. :total_seats)
  occupied_seats: integer(0 .. :total_seats)
  # length checks the list, "of string" could be implicit
  passenger_list: list(0 .. :total_seats) of string

# further validation and processing
processing:

  # & references a previously declared field
  # :flights_table could be a list or a hash
  # this might be more appropriate to be on
  # the previous "parameters" instead of here

  - exists &flight_number in :flights_table
  
  # maps the flight type code into a descriptive string
  # using the flight_types hash

  - map &flight_type into :flight_types
  
  # some simple and obvious checks

  - check $occupied_seats < &total_seats
  - check &passenger_list = &occupied_seats

# in-template variable declaration
declare:
  flight_types:
    A: Commercial
    B: Non-Commercial
    C: Cargo
[download]

In fact, I actually really liked this idea. I might consider implementing it, if I have the time. ;-)


acid06
perl -e "print pack('h*', 16369646), scalar reverse $="

The thing is, your example on location and associated ZIP code syntax, is one example of why a database lookup could be a good idea in a data verification language. Do you really wish to pile rule upon rule, in "code", for a single association, location<->ZIP? It seems to me like a table holding those associations would be a better idea.

• perl functions
• javascript field actions
• sql constraints and triggers

I am manually replicating rules across different languages. I'd like is to be able to state these rules at one in place using one language.

Validation often takes you outside your perl comfort zone into other subsystems and languages. Often the same validation rules are replicated in different places using different languages. What a burden!

In short, I kind-of like the idea of a mini-language, and an interpretor, but what would really sell it to me is the added ability to use it as a cross language/platform lowest common denominator - specify my rules once translate it into validation libraries in other languages such as javascript and sql.

I've implemented the Verify language once. Having done so once, I've thought about translation. It's so small and simple, a lot if open to interpretation when translating it.

Language translation is easy. Any 1 op maps to 1 or many more. Verify is simple enough, no memory allocation, type saftey and what not, it should be cake. :)

What kind of db validation beyond unique and fk constraints are you thinking of? I'd advise against DB specific stuff if you can help it, since switching or using a product on another DB isn't your target isn't fun.

Modules such as Class::DBI has wrecked me forever when it comes to low level grovelling through databases with SQL validating primary keys in any language...

To warrant serious consideration, a validation language it'll need to operate at a similar level of abstraction and portability. I'd like to write...

  unless(get_Person_Company(:salesperson, :company))
    Return "E_INVALID_SALESPERSON"
[download]

...and remain blithely unaware as to whether this is a cgi-form or an uncommitted database entry.

The call to accesor get_Person_Company() remains the same.

I'd agree with acid06's comments that different layers of abstraction is the way to go.