Paradox Community

Items in pnews.paradox-dos

Subject:Re: calc
Date:Tue, 27 Mar 2018 12:02:53 +1000
From:Bernie van't Hof <berniev@bje.com.au>
Newsgroups:pnews.paradox-dos
Solution v2.

An incoming 'num' token predicted a date or a number (See START_TARGETS array below).

On the basis that:

* a NON-WILDCARD DATE is pre-parsed by the lexer to a 'dateSql' token.
* A 'num' token the lexer cannot develop into a non-wildcarded date is left alone.
* Only a date column is allowed to contain a wildcarded date.

.. If not in date column, I override the 'num' token to 'NUM' which only predicts a NUM type
in START_TARGETS.

$key = ($ptype == 'num' && self::COL_TYPES[$this->colType] != self::DATE)
     ? self::NUM
     : $ptype; // the incoming token type
$types = self::START_TARGETS[$key];

I also made RIGHT_TARGETS op-sensitive, which simplified some stuff.

     public const NUM = 'NUM';

     public const DATE = 'DATE';

     public const STR = 'STR';

     private const PLUS = '+';

     private const MINUS = '-';

     private const MULT = '*';

     private const DIV = '/';

     public const COL_TYPES = [
         'NUM'      => self::NUM,
         'DATE'     => self::DATE,
         'STR'      => self::STR,
         'DECIMAL'  => self::NUM,
         'VARCHAR'  => self::STR,
         'SMALLINT' => self::DATE,
         'DOUBLE'   => self::NUM,
     ];

    /**
      * START_TARGETS[TokenType]=[TargetTypes]
      */
     private const START_TARGETS = [
         'dateSql'    => [self::DATE],
         'today'      => [self::DATE],
         'num'        => [self::NUM, self::DATE],  //           <=========
         'numexp'     => [self::NUM],
         'dot'        => [self::NUM],
         'unary'      => [self::NUM],
         'string'     => [self::STR],
         'strlit'     => [self::STR],
         'wild'       => [self::NUM, self::DATE, self::STR],
         'NUM'        => [self::NUM],
         'DATE'       => [self::DATE],
         'STR'        => [self::STR],
         'DECIMAL'    => [self::NUM],
         'VARCHAR'    => [self::STR],
         'SMALLINT'   => [self::DATE, self::DATE],
         'DOUBLE'     => [self::NUM],
     ];

     /**
      * RIGHT_TARGETS[LeftType][Op]=[TargetTypes]
      */
     private const RIGHT_TARGETS = [
         self::NUM  => [
             self::PLUS  => [self::NUM, self::DATE],
             self::MINUS => [self::NUM],
             self::MULT  => [self::NUM],
             self::DIV   => [self::NUM]
         ],
         self::DATE => [
             self::MINUS => [self::NUM, self::DATE],
             self::PLUS  => [self::NUM]
         ],
         self::STR  => [
             self::PLUS => [self::STR]
         ],
     ];

query

transact | Amt           |
          | _x, CALC 6-_x |

endquery

SELECT DISTINCT
'6' - `Amt`
FROM `transact`
ORDER BY '6' - `Amt`

query

transact | Amt             |
          | _x, CALC 6 - _x |

endquery

SELECT DISTINCT
'6' - `Amt`
FROM `transact`
ORDER BY '6' - `Amt`

query

transact | Amt                |
          | CALC 6+23-jun-2015 |

endquery

SELECT DISTINCT
DATE_ADD('2015-06-23', INTERVAL CEIL('6') DAY)
FROM `transact`
ORDER BY DATE_ADD('2015-06-23', INTERVAL CEIL('6') DAY)

query

transact | Amt                |
          | CALC 6-23-jun-2015 |

endquery

Error: Query Table:transact Column:Amt Posn:Line 1 Column 18 Invalid expression

The structure proved ok.

- Bernie



On 24/3/18 1:11 pm, Leslie wrote:
> 
> On 24/03/2018 3:05 AM, Bernie van't Hof wrote:
> 
> Without getting too involved once more....
> 
>> The current perception is that the above can only be solved by reading
>> further tokens and will require unwinding those that prove unneeded. So
>> far it has not been necessary to rewind tokens and to add this ability
>> would be tricky.
> 
> My point from the start is that:
> 
> what has *always* been required is the construction of an expression tree or more generically
a Binary Tree.
> 
> If you are not doing this then you are making life more difficult than it should be. Based
upon your posts it appears 
> that this is the case.
> 
> 
> _x, calc 6-_x should never be a problem for a decently written parser. Without really thinking
it through, "calc" is 
> simply a function call passing a sub-expression as its parameter.
> 
> I do not care if paradox raises an error, which BTW I believe is a Bug in Paradox as the
comma is a sub-expression 
> terminator.
> 
> So throwing _x, away you are left with calc(6 - _x) which throws an error because _x is
now undefined, but if we said:
> 
> Calc(6 - 3) then I expect it to not fail.
> 
> Therefore _X, Calc(6 -_x) failing to resolve is a bug in the Paradox Parser as I perceive
it to be unintentional. Dare I 
> suggest they also did not use an expression tree.
> 
> 
>> BTW I think I sorted out unaries too.
> 
> Which would be trivial with an expression tree. The fact that they needed figuring out
at all is a concern.
> 
> 
> My last comment this month on this topic is that you need to use the right method for the
job. You never hammer a screw 
> or use a screwdriver for a nail.
> 
> I believe you need to rethink the way you are handling the expression internally as trivial
things are becoming overly 
> complicated.
> 
> So in case it got lost in the post: use an *Expression Tree* Luke.
> 
> FWIW
> 'til next month
> Leslie.
> 
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
> 


Copyright © 2004 thedbcommunity.com