Paradox Community

Items in pnews.paradox-dos

Subject:Re: qbe to sql
Date:Tue, 17 Oct 2017 17:02:19 +1000
From:Bernie van't Hof <berniev@bje.com.au>
Newsgroups:pnews.paradox-dos
1. Stream. Read SC file chr by chr identifying type of each chr eg tilde 
is 'tilde', alpha is 'alpha' etc.

2. Lexer. Read stream output analysing the first character after white 
space to build tokens eg a tilde is a 'var' token and its value becomes 
the ensuing string chrs. A double quote starts a string literal. An 
alpha character could presage a number of things including a keyword eg 
Do_It!

3. Parser. Each token has certain structures associated with it. eg A 
token of type 'keyword' and value 'home' generates php code string to 
call the static function HOME() in the run-time.
SC input: 'HOME'
php output: 'P::HOME();'
This is a big long switch statement with one case for each keyword.
Many have the same structure eg commands with no arguments, so they are 
all handled at the end of a bunch of consecutive case statements.
It gets a bit more complicated with function calls and queries as their 
status needs to be tracked.
eg
                 case 'scan':
                     $lex->Next();
                     $out = PHP_EOL . "/* SCAN */" . PHP_EOL;
                     $out .= "if(P::NROWS() > 0):" . PHP_EOL;
                     $out .= "P::HOME();" . PHP_EOL;
                     $out .= 'do{' . PHP_EOL;
                     $scanFor = false;
                     if ( ! $lex->TryType('colon') &&
                             $lex->TryVal('for')) {
                         $scanFor = true;
                         $cond = $this->Expr($lex);
                         $out .= "if($cond){" . PHP_EOL;
                     }

                     $out .= $this->Parse($lex, 'scan') . PHP_EOL;

                     $lex->Expect('endscan');
                     if ($scanFor) {
                         $out .= "}" . PHP_EOL;
                     }
                     $out .= PHP_EOL . "}while( ! P::ATLAST());" .
                             PHP_EOL;
                     $out .= "endif;" . PHP_EOL;
                     $out .= "/* ENDSCAN */" . PHP_EOL;
                     break;

                 case 'endscan':
                     break 2;

4. Each function in the P:: run-time is a stub to the php code (library 
if you like) to perform the required actions emulating the pdox dos code 
base.

5. Each entry and exit of a function calls the run-time to handle 
variable scope. php is function scoped, where pal has a rather horrible 
mix of globals, and hierarchical globals. This caused me some grief 
early on but I think it is now mostly under control.

The result is a php file. The SC file is no longer needed. The php file 
is not nicely formatted but my IDE (PhpStorm) makes it pretty.

So the result is php, interpreted pal. Translation Target is 100%, which 
is not difficult. Replicating the pdox dos code behavior is more difficult.

For display I chose to use a browser communicating via websockets (for 
speed, bidirectionality and simplicity) with an instance of the 
interpreted pal app running under php cli as it is a long-running app. 
Given the improvements in browsers, quite a lot of code can be run in 
the browser.

Data files are converted as a migration step.
The data structures (ie not the data) is needed at run-time.
The whole lot is read and converted to sql table generating sql files 
and sql data.

Variables in php are $.. They are converted from pal 'var' tokens during 
parser code generation.

I'm pleased to say that the parsing stage seems to be working properly, 
as is the run-time handling of variable scope, functions, queries etc.

Is there a code generation tool that would handle all this? Can pal be 
defined by ebnf? I don't know enough about the subject so I rolled my own.

One could either re-write an app (which would be a on-off), or emulate 
paradox. I chose the latter as it maintains all the business logic of 
the original app and is re-usable. If re-writing the app you still have 
to account for paradox behavior anyway.

In many ways this project is making me realise just how dense *I* am but 
I continue to learn heaps.

What are you like with javascript? (That's my weakness, among others).

- Bernie

On 17/10/17 6:01 am, Larry DiGiovanni wrote:
> Bernie:
> 
> Thanks for your response.  I am still struggling with this though.  Are 
> you trying to convert the PDOX DOS app into a Web App, or are you using 
> PHP CLI and some sort of UI library to render a locally executed app?
> 
>> Wanna help?
> 
> Maybe.  I've got a good bit of experience writing code generators.  But 
> I have very little PHP experience, and even less experience writing 
> source code parsers.
> 
> If I were rewriting a Paradox for DOS application as a /Web/ 
> application*, I think it would be particularly challenging to tackle 
> some of the UI characteristics of PDOX DOS.  As a desktop app, it's 
> probably a little less challenging, particularly if you are planning on 
> rendering the GUI with some sort of terminal emulation library (e.g., 
> curses).  But I am assuming you are writing a tool which is intended to 
> produce x% of the final code, with x being some number as close to 100% 
> as possible.
> 
> It almost sounds as though you aren't writing a tool to rewrite an 
> application, but rather a tool that renders the active state of the 
> application (any application) in real time.
> 
>> Data is converted from db and px files into sql format, including 
>> secondary indexes. Set and Val files also interrogated to get the full 
>> picture.
> 
> When?  During some pre-go-live migration outage, or during application 
> execution?
> 
>> Run-time/interpreter layer fixes up variable scope etc etc.
> 
> This statement is maybe the source of my confusion.  In a random PDOX 
> DOS app, you can only count on the scope of a variable at runtime.  So 
> the PDOS DOS app would have to be running, or the translated app would 
> have to be written in a language that allows yucky variable scoping 
> (which PHP does), but you'd have to retain the variable names - can you 
> do that in PHP? Thought they all have to start with $.
> 
> Sorry for being dense.  :-)
> 
> -- 
> *If I were to approach this, it'd lean heavily on code generation 
> techniques, but it would essentially be a rewrite.
> 
> -- 
> Larry DiGiovanni
> 


Copyright © 2004 thedbcommunity.com