# 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]

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

Wait. What? I think you are misunderstanding the difference between the language and the interpreter. The interpreter interprets a language. I'm sure CDBI uses a perl interpreter for the custom sql language it uses, though it may be c, or c++. Doubt it's ruby. The point of it is to BE code since you can't do branching w/o some level of code. I.e. If your country is england or canada, your postal code can be alphanumeric. If it's a small island (like mine), you don't have one.

By using Yaml, yaml is your language, and I'm assuming perl is your interpreter. For this, Verify is my language, and my interpreter is written in the native language. Basic, perl, java, c, fortran, whichever.

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.

Then this RFC isn't for you. As I've pointed out, if you can seperate everything in your regular langauge, and everything is done well and such, great. It shows you have diligence and the people around you do too. It's the same argument I have for php. Yes, php is a language, and if you are very diligent w/ it, you can do great things. Problem is a lot of people out there aren't, and try to short cut themselves into oblivion.

Take a look at the internals of drupal. Or osCommerce. Not fun.

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.

I beg to differ. For one, what constitutes data as being valid, vs logic that manipulates the data (controller stuff), the actual model, the visual-ness, the confiuration alnguage for my application and such, can all be seperate. I would not wish to use my model tools to calculate pi, my visual stuff to start doing DBI calls. Nor would I want my configuratoin language to be used for validating of data. It's been done before, and it can get quite messy trying to describe dependencies.

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 there in lies the rub. Some people will believe in doing it all in code, some people believe the XML format of jakarta validation is awesome, and people like you believe in YAML. This is really not a problem. To give you my personal opinion, the XML format, describing dependency is a pain when you wish to start saying, certain combinatios are good. Heck, try doing password valdation (password=passwordverify). One winds up writing a lot of validation stuff in native code, and parameter passing in the XML format. It gets /very/ verbose. It can also be error prone.

Native code, like using perl, or c, or basic, or java, gives me too much power. It becomes like php, as I've said before, 3500 core functions. What do I need any of that for? It's like writing queries IN perl. SQL is so much better suited due to design.

As for yaml, yaml is a nice. Really. But you broke a cardinal rule, simplicity. I do not want type checking. It's why things like excel work so well for it's formula language. It takes a little effort to do things wrong. In c, it's easy. Try miscasting something. I also didn't care for the abundacy of sigils. I did not wish to use them, but I ran into a problem with collisions of variable names, so :password is an external variable, where password isn't. It becomes like some SQL languages.

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

Please do. What we need are good systems being written. Bad systems weed themselves out. We all evolve. We write less in c because other languages are "easier" to write in, and do more for us. We have ACID compliant databases, 'cause dealing w/ semaphores can be such a pain in the ass on the coding level. We have LWP and Net::FTP because it's getting old, rewriting ftp clients all over the place. The purpose of this is so that I can write a good RFC, that is complete, and helps me write a complete system that is a puzzle piece in a set of pieces for a complete architecture.

I don't have a good answer for this. So bear with me. Maybe the salesperson example is bad, because of the context. I.e. a valid node id is numeric, where is a usable one is somewhere below this node number at creation time, something higher in the future.

I probably shouldn't have specific data checking that is DB related built in.

Btw, in the US, zipcodes are all 5 digit,then and extra 4. 00000-0000 is valid in syntax,but not in the context of being available, or usable. Just as the name xxxxxxyyyyy isvalid in most countries that use the alphabet, but you can't pronounce it.

Thoughts?