On 11/12/2017 1:59 AM, Bernie van't Hof wrote:
> Leslie, you make it all sound so easy.

It is easy when you have the specification in your hand, without it you 
have no choice but to go back to basic mathematics. But still not too hard.


> But if we can be practical for a moment, what are the expected outcomes
> of the following PDOXDOS4.5 queries?
>
> CCP Default date format is DD-Mon-YY
>
> QUERY
>
> Tbl | Date          |
>     | CHECK 2+23-.. |
>
> ENDQUERY

This could be interpreted multiple ways as there are no brackets 
indicating the order of operator precedence.

But I would treat .. to have the highest order (higher than both the / 
and * operators in numeric calculations actually) and resolve the 
pattern 23-.. first.

And then because there is no Day, Month, Year function specified around 
the 2, I would default to the number being in days because we know this 
is a date field and since "forever" date API's uses days unless 
otherwise specified.

Thus the pattern gets resolved first and then add two days to the 
result. So the "pcode" would build to something like:

Days(2) + (Day(Date) == 23)

I would be interested in what actual result your test data delivered, 
because if you get it wrong (and by wrong I mean not as expected) then 
you could end up with zero matches if you resolve to 25-.. which is 
likely not what you want.


> QUERY
>
> Tbl | Date                 |
>     | CHECK 21-..-2016 + 2 |
>
> ENDQUERY

Again the + 2 is done after the pattern matching on the date as per the 
operator precedence rules.

My "Pcode" would be:
(Day(Date) == 21 and Year(Date) == 2016) + Days(2).

Looks simply with hard-coded values, so using a Parameters for the year:

CHECK 21-..-~Parameter + 2

would resolve to:
(Day(Date) == 21 and Year(Date) == ~Parameter) + Days(2).

If the result is not what the user wanted or they suspect it may not 
resolve the way they want it then a smart user would do the following:

CHECK 21-..-(~Parameter + 2)

which the expression evaluator would resolve to:
Day(Date) == 21 AND Year(Date) == (~Parameter + 2)

Of course if it were me I would code my expression parser to parse 
left-to-right and produce postfix representions of infix expressions as 
it makes the actual expression evaluation simple(r).

I suppose I am 30+ years too late saying this but those of us from a C 
world understand the need for brackets especially when using pointer 
arithmetic. My philosophy has been why not throw a few brackets in there 
to help things along a bit even in SQL script.


Anyway, this is where things can get tricky, because now we are asking 
is the goal a complete emulation or not?

If it is an emulation then the bugs must also be emulated. If this is a 
translator/conversion then some leeway is allowed and undefined results 
need not match, they are simply undefined.

So based upon your goal, yes you need the QBE specification specifically 
used by Paradox for DOS. My guess is that ODAPI kept the same rules and 
thus so did the BDE. But the Borland guys may have fixed/changed things 
along the way - this is what we do not know.

So, is this an actual emulation or a translation project ?
Interesting either way !

Leslie.

> NB: They do not throw errors.
>
> - Bernie
> On 10/12/17 9:47 pm, Leslie wrote:
>>
>> On 10/12/2017 7:54 AM, Michael Kennedy wrote:
>>
>>> Yes - thinking of how to parse numerous "-", ".", "..", and "/" chars is
>>> frightening... I expect there are numerous "expressions" that could be
>>> validly interpreted in multiple, totally different, ways.
>>
>> Parsing is not the issue - many of us had to write language parsing
>> rules in the 80's as a mere exercise.
>>
>> What *is* the problem is knowing what the existing rules for QBE in
>> Paradox are so that we parse the file/string correctly.
>>
>> I have been looking through my archives for the QBE specification this
>> afternoon and have not had any luck at this time. I do have a copy of
>> the book "Paradox Queries" by Dan Ehrmann but Bernie wants a Paradox
>> for DOS specification which makes that one too modern.
>>
>> I will keep looking, but if I do not have any luck, I will email a few
>> team mates from the 80's to see if they kept the original QBE
>> specification - I know it exists because I had a photocopy from
>> Borland Australia (back when they were helpful).
>>
>>
>>> And, I've always had huge respect for the folks who developed the
>>> internal ISAM/B-Tree handling, record locking, etc.
>>
>> How it works is nothing special really, in fact quite common back then.
>>
>> IMO, what makes a Paradox database (on Windows) that little bit extra
>> special over others of the time is the ODBC interface and support by
>> third party tools such as Crystal Reports.
>>
>> I co-wrote something similar back in the late 80's which we used in
>> parallel with Btrieve 3.5/4.0.
>>
>> I have rewritten that library twice since then as I use it in other
>> applications today. It does super-fast data retrieval (faster than
>> Paradox actually) and does not need an engine like the BDE. If only it
>> had an ODBC interface, but I am 25 years too late on that one.
>>
>>
>>>> That they got as far as they did is testament to their skill, but the
>>>> hole they were digging was getting deeper and filling up with edge
>>>> cases.
>>
>> The hole they dug was to under-appreciate their developers. Once the
>> external Marketing people got into the heads of Borland management
>> they were finished. IMO, Borland peaked around 1992 and it has been
>> downhill since then, a real shame.
>>
>>
>>>> As it is unlikely I can do better than they did and even less likely I
>>>> could reproduce all their outcomes, I might have to introduce some
>>>> little rules. We'll see.
>>
>> As I have previously suggested, the standard practice is to create a
>> configuration file which allows you to specify default rules but then
>> allows the installer/caller to alter them.
>>
>>
>>> I think that would be entirely acceptable. Also, I expect most/all
>>> developers got burned with numerous "odd" expressions, and that they,
>>> therefore, used only very safe and conservative code, and kept far away
>>> from all the edge conditions that you've observed.
>>> Mike
>>
>> Exactly, creating a rule/configuration file is the smart approach and
>> if you code that in from the beginning it costs almost no additional
>> time and gives you flexibility forever.
>>
>> Leslie.
>>
>>
>> ---
>> This email has been checked for viruses by AVG.
>> http://www.avg.com
>>