Thanks Mike,

PAL: "str" + 1 => "Expecting a value of ALPHANUMERIC type" (I'd forgotten that)
PHP: "str" + 1 => "str1"

PAL:
i="i"
t="2"
p=i+t   => p = i2
i=1
t=2
p=i+t   => p = 3 (no error)

form, val and set files are currently parsed on demand i.e. when loading a pdox image, allowing
changes using pdox.
But that can change as all the information is put into objects that could be saved, rendering
the form file redundant. 
But until there is a form editors for the converted data ...

I just thought of something else. RUN script's are also optionally always parsed on the fly,
and always if the sc is 
later than the converted php. I must check, but if there is a php and no sc then it should just
load the php.
The same logic is planned (not yet done) for forms.
And as I think about it there is no obvious reason this logic should not apply to tables, and
from there an entire pdox 
app. Sounds like a goal.

Given:
a) The converter works out many properly
b) Edit search/replace even on many files using a modern IDE is trivial
c) The modern IDE is also type checking and flagging possible errors
.. it is not such a huge undertaking, albeit a bit tedious

I didn't mention the DoPlus() idea, but I had thought about it. For some inexplicable reason
I perceived it too hard and 
make the converted code appear too different to the original, which in hindsight appears unreasonable.
It would only be 
required in situations where the parser can't decide. It is also consistent with other keywords
the code generator 
changes when they clash with php e.g. ECHO becomes DOECHO() etc.

Mmmmm ...

Now to get ready to go up the hill and drink beer with the neighbours.

- Bernie


On 25/8/18 9:42 am, Michael Kennedy wrote:
> Wow!
> 
> Just to clarify two trivial PAL queries, Bernie - that I've forgotten about:
>    - In PAL, if we have a string var "+" a num/int var, I presume Paradox will reject
this operation?
>    - In PAL, if we assign var1 and var2 as strings, do a "+" on them, and, later on, within
the same scope, try to 
> re-define them as nums/ints, and try to a "+" on them, I presume Paradox will object?
> 
>> 1. Add one or more new operator(s) to PAL to force correct operation (easy), but this
would require modifying PAL 
>> source code and it wouldn't work in pdox any more, and the pdox forms calculated fields
editor won't allow them.
> 
> A huge undertaking on a large app. And, if an app uses any of those WPP libraries, etc,
that we discussed previously, 
> all of the library code must also be reviewed - bordering on an impossible task...
> 
>> 2b. (Thinking aloud) Parsing and translating calculated fields could be done at the
time a form file is parsed. This 
>> fits with the plan to store, cache and modify converted forms.
> 
> Is that form-file parsed only on a single, initial, conversion process, or as a pre-process
step for every app run?
> 
>> 4. Add directives via pal comments to tell the translator what to do. This does require
modifying the src PAL code, 
>> but survives repeated translate runs, but doesn't address the forms calculated field
problem.
> 
> Also a huge initial undertaking... see above...
> 
>> 5. Ideally this could all be handled by code inserted into the generated php (like
variable scope management is done 
>> currently), but that could make the generated php look very different to the original
PAL, and potentially a lot more 
>> complex, which would make it harder to work with and maybe more fragile.
> 
> Well, you're the best person to call on this one?
> 
> Presumably, it's not easy, or maybe impossible, to just have a simple "zzz = Do_Plus(xxx,yyy)"
function, where the three 
> parms could be of type "Any", and the function then identifies the parm-types, and performs
the relevant operation?
> 
> Sorry I've no good suggestions.
>    - Mike