legacy 5.x syntax deserves to be abandonned

classic Classic list List threaded Threaded
6 messages Options
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

legacy 5.x syntax deserves to be abandonned

Hello,

While fixing

http://bugzilla.scilab.org/show_bug.cgi?id=15623
http://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.

However, all problems can be fixed by yanking lines 661:666 in
parseScilab.yy (666: Number of the Beast).

S.

--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: legacy 5.x syntax deserves to be abandonned

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.
>
> However, all problems can be fixed by yanking lines 661:666 in
> parseScilab.yy (666: Number of the Beast).
>
> S.
>
Here are the error messages after the fix in parseScilab.yy:

--> max(,)
max(,)
      ^
Error: syntax error, unexpected ","

--> max(1,)
max(1,)
       ^^
Error: syntax error, unexpected )

S.

--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: legacy 5.x syntax deserves to be abandonned

In reply to this post by mottelet

The following (fixed) bug

http://bugzilla.scilab.org/10279

shows that such a syntax was considered as an error, but only for user-defined functions. (it has not been fixed at the parser level). I don't see any reason why the syntax should be accepted for built-in functions.

S.

Quoting Stéphane Mottelet <[hidden email]>:

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.

However, all problems can be fixed by yanking lines 661:666 in parseScilab.yy (666: Number of the Beast).

S.

--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.utc.fr/~mottelet

_______________________________________________
dev mailing list
[hidden email].<a href="orghttps://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev" target="_blank">orghttps://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev




_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: legacy 5.x syntax deserves to be abandonned

In reply to this post by mottelet
Le 22/06/2018 à 10:28, Stéphane Mottelet a écrit :

> Hello,
>
> While fixing
>
> http://bugzilla.scilab.org/show_bug.cgi?id=15623
> http://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).

Does your proposed patch also prevent them?

Samuel

_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: legacy 5.x syntax deserves to be abandonned



> Le 20 juil. 2018 à 20:24, Samuel Gougeon <[hidden email]> 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....

S.

>
> Does your proposed patch also prevent them?
>
> Samuel
>
> _______________________________________________
> dev mailing list
> [hidden email]
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: legacy 5.x syntax deserves to be abandonned

Le 20/07/2018 à 20:30, Stéphane Mottelet a écrit :

>
>> Le 20 juil. 2018 à 20:24, Samuel Gougeon <[hidden email]> 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

_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev