Sunday, December 9, 2018

My expression analyzer for the default syntax engine

You can to parenthesis, add, subtract, multiply and divide as well as increment and decrement.

I used a trick, sorted the syntax tag table by binding priority. Hence the expression parser can easily determine of the operation needs to compute a sub expression first. The syntax tag table just contains the words and syntax type for the language; easy look up, but can be slow. Like I did with the html scrapper, go though once and identify tags according to the table, then work the tag list.

My parser is coming in at 350 lines of code, one single file no headers except clib. On start of console, the default syntax is oaded. After that, the user can replace it. The best possibility is to make the other alternatives a shared library. It works the same, but as a shared, the dispatcher can put many more on the stdio bus, the loaded syntax engine getting multiplexed streams. 

Multiplexing input to Python is good because the plan is that multiplexing streams have adopted a common semantic, the enterprise configuration. We want them all to share the bus, python ro forth provide the semantics in their dictionaries, all machines and humans have automatic ad hoc access to the enterprise data structure.

So, for example, the enterprise manager is getting a trouble call, but the machine in question is already in communications with the Python 'dictionary methods'; a remote machine or human is already reporting issues in the prescribed fashion, the enterprise manager extracts the data for analysis using python dictionaries. The key is the console dispatcher operating via the linux command bus, thus all the linux utilities reporting according to company methods.  Any utility you need, just find the map between the morass of flags and your company method, then format the data on return as the company desires.  Add simple Xchars and you get smart, immediate and clear data everywhere.

No comments: