if one or more elements is a string, the whole thing has to be a string.. 
date plus date invalid.. date plus number or number plus number, good.. 
that's what we start with, of course

--

Steven Green
Myrtle Beach, South Carolina, USA

http://www.OasisTradingPost.com

Collectibles and Memorabilia
Vintage Lego Sets and Parts
- and Paradox support, too
"Bernie van't Hof"  wrote in message 
news:5b80b2a5@pnews.thedbcommunity.com...

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