Default syntax

int count=6;
while(count) { cmd arg1 arg2 arg3; count--;}

There, an example. Intent is to deliver the cmd sequence to the linux bus 6 times.  The syntax treats undefined tokens as valid linux command syntax, and emits them onto the linux command bus.

Beyond this, my default grammar does little else. Steps to starting: Bring up the console loop, and if the default syntax is all you have, load that module. Otherwise Forth or Python can start console loop in the reverse order and become the syntax engine.  The interfaces to existing syntax engines all about:

ExecCommand(int *argc,void * args);  // provided by console loop

But this is really a pseudo name for Entry(argc,args); So linking the console loop as a shared loadable gives it the same interface as any other loadable. The console loop can load another version of itself, for no reason. The console loop loader does not track which devices are loaded, at the moment.  But it is worth putting in duplicate checks and some version control for modules, later.
Starting a new syntax engine:
LoadModule name; // New Eninge
UnloadModule default; // do this last, remove default engine

I will try to get a good lab copy of parse  uploaded to the blog file links within a day.

Once any syntax engine connect to console loop with this console entry point, then it can control the linux command bus. The console bus maintains the list of entry points to the loaded subsystems, all of which are available to the syntax engine via ExecCommand. So console loop is the switching and loading manager for sub systems on the linux bus. The command format is considered full duplex, the args[] thus being executable assembly with arbitrary access. I particular, the bottom of args[] is available for return values, like the Forth return stack.

Linked as a shared object, console loop will not load a syntax engine. Otherwise it loads the default, which may be swapped out for any other loadable syntax engine.  The default syntax engine presents:
Parse(int *argc, void * args[]); // args[1] points to the source text. The name of the language, for you marketing types, is Default, with all of four or five syntax forms.



The syntax engine sees a transparent format for all subsystems arc and args provide the executables for  cmd arg1 arg2...  as seen on the command line. As in: The string command line is presented as the array of null terminated strings, a kind of ad hoc assembly language format.

Also, in the default syntax engine,  the while is executed from the linux command bus. Thus default syntax is interactive on the command line, as is an expression analyzer and the groupers ( "{}()"), which yields linux commands: While, Block, Expr // the three main execution unis for default syntax. Casting is done and setup prior to executing. So args[] is truly an assembly language format, slower than frig because the opcodes are executed by a c routine.

The console loop, all 100 lines of it, can be linked as executable or shared lib.

But that is the extant of my two pass scripting engine, and slow operation obtained, but very simple code implementation, light weight, limited, like a boot syntax to get you going and run standalone tests. Getting a scripting language embedded at all, with variable support, under 300 lines of c code is a great deal, a cut n paste with gcc gets you powerful enough scripting to start the day, a boot of your command and control with no external headers except stdio.

Formats of void *args[]. So far I have specified char* strings formatted as null terminated text or string coded int.  I have been back and forth on casting args[0] as an immediate int, it is a gcc pain. But eventually args have to have immediate int for easy passing between sub systems. This is necessarily an expansion of the definition of linux command bus but should be transparentto subsystems who do not use it.  But my default syntax has no float, no double, no long, no char, and no array types  as native formats for linux args, I do not think they are needed in the default, native syntax engine.