[Scilab-Dev] legacy 5.x syntax deserves to be abandonned

[Samuel Gougeon]

Le 20/07/2018 à 20:30, Stéphane Mottelet a écrit :
>
>> Le 20 juil. 2018 à 20:24, Samuel Gougeon <sgougeon at free.fr> a écrit :
>>
>>> Le 22/06/2018 à 10:28, Stéphane Mottelet a écrit :
>>> Hello,
>>>
>>> While fixing
>>>
>>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=15623
>>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=15624
>>>
>>> I discovered that gross syntax errors such as
>>>
>>> max(,), max(1,) mean(,)...
>>>
>>> are not trapped by the parser. As a consequence, tokens of type internalType:ScilabVoid are given to the gateway in the input arguments.
>>>
>>> There are a lot of scilab functions which do not correctly handle this. For example,
>>>
>>> max(1,) and atan(1,) crash Scilab
>>>
>>> max(,), gives a message about a missing overloading function for ScilabVoid type.
>>>
>>> Why such an dumb syntax has been kept as valid in Scilab 6 ? Does even somebody remember if there exist some legacy code needing this ?
>>>
>>> There is a potentially huge number of gateways to be fixed because of this too permissive syntax.
>>
>> If you consider the very close syntaxes like
>> myfun(a, , c)
>> or
>> myfun(, b, c)
>> also as too permissive and to be forbidden, then we would definitely disagree:
>>
>> To me, they are to most handy way to skip an argument (obviously provided that myfun() handles it correctly).
> The problem is that the number of functions that actually *do not* handle it is unknown/unbounded....

Why is it a problem? The same question can hold about the unknown number 
of functions that expect [] to skip an argument, or that expect "" 
instead, etc. This is just a matter of documentation.

If being able to handle myfun(,b,c) or myfun(a,,c) becomes impossible, 
this would really be an issue, not a documentation one.
Just skipping arguments values at kept positions to set the default 
values is more and more my way to write my macros.
It is more robust than using named arguments, and simpler than each time 
asking to oneself which value must be entered to set the default one.
Scilab 6 is a bit better than Scilab 5 about "void" types. Their 
relevant usage must not be prevented by any parser modification.
myfun(a,) is not relevant, indeed, since it is equivalent but less 
simple than myfun(a).
And the bug http://bugzilla.scilab.org/10279 is just about this ending 
comma case, nothing more.


>> Does your proposed patch also prevent them?

Shall we understand "yes"?

Samuel