>>>>>

>>>>>* this is ok
>>>>>? 10-3-2
>>>>>* typo 3 => bad result (better a syntax error !)
>>>>>? 10--2
>>>>>* Need a constraint in the grammar
>>>>>? 10-(-2)
>>>>>

>>>>
>>>>Why would that be wrong? If I substract 10 minus negative two, that is the same as 10 plus 2. What do you expect, and why?
>>>
>>>Of course, but the question is how you should write this.
>>>With 3 or more signs VFP fail! VFP requires brackets.
>>>I'd rather the obligation of the brackets with 2 signs too.
>>>
>>>Why this allow a small typo to create a valid expression,
>>>but that is a calculation that the programmer did not want to do!
>>>This may result in errors discovered after months,
>>>you have lots of corrupted data
>>>and to find the wrong expression you become crazy.
>>>
>>>The only help they can give you the language of development is the syntax,
>>>I prefer a rigid syntax, to avoid a future in a mental hospital.
>>
>>So you're asking for is a change in grammar in the special case of a subtraction so that a unary minus will be forbidden on the right-hand side?
>>
>>i.e. the following will generate error
>>? a --b
>>? a - -b
>>but these won't
>>? a+-b
>>? a*-b
>>? a/-b
>>? a%-b
>>? a^-b
>
>My ask is for unary minus or plus within brackets when before there is a aritmetic operator
>
>>i.e. the following will generate error
>>? a --b
>>? a - -b
>>but these too
>>? a+-b
>>? a*-b
>>? a/-b
>>? a%-b
>>? a^-b
>
>this is my ask
>? a -(-b)
>>? a -(-b)
>>? a+(-b)
>>? a*(-b)
>>? a/(-b)
>>? a%(-b)
>>? a^(-b)
>
>then this return error
>? a(-b)
>
>This reduces the chances of a typo run into the application.

If that's the direction you're going, then why not simply require parenthesis on unary minus?
a = (-b)
a == (-b)
a < (-b)
a <= (-b)
a > (-b)
a >= (-b)