&&, ||, {} as cell-builder not overloadable: official?

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

&&, ||, {} as cell-builder not overloadable: official?

Hello,

Could we have the confirmation that the new Scilab 6 operators &&, ||,
and {} heterogeneous concatenator are not currently overloadable?
Is this their official stable status (=> creating some first official
exceptions), or should it be considered as bugs to be reported?

Thanks
Samuel

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

Re: &&, ||, {} as cell-builder not overloadable: official?

Hello Samuel,

You are right, there is no overload for these new operators.
for || and &&, it seems to be OK, we can create new overloads like
%x_gg_x ( || ) and %_hh_x ( && ) for example.

but for {} it would be difficult, cell creation accepts ALL types so how
to detect and call overloads ?

Antoine
Le 15/01/2019 à 00:25, Samuel Gougeon a écrit :

> Hello,
>
> Could we have the confirmation that the new Scilab 6 operators &&, ||,
> and {} heterogeneous concatenator are not currently overloadable?
> Is this their official stable status (=> creating some first official
> exceptions), or should it be considered as bugs to be reported?
>
> Thanks
> Samuel
>
> _______________________________________________
> dev mailing list
> [hidden email]
> http://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: &&, ||, {} as cell-builder not overloadable: official?

Le 15/01/2019 à 10:47, Antoine ELIAS a écrit :
> Hello Samuel,
>
> You are right, there is no overload for these new operators.
> for || and &&, it seems to be OK, we can create new overloads like
> %x_gg_x ( || ) and %_hh_x ( && ) for example.
>
> but for {} it would be difficult, cell creation accepts ALL types so
> how to detect and call overloads ?

You are right. This concatenator can't be overloaded. Let's document it
in its forthcoming page.

Do you think that overloading for || and && could be ready for Scilab
6.0.2, to make Scilab 6.0 regular?

_______________________________________________
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: &&, ||, {} as cell-builder not overloadable: official?

Le 15/01/2019 à 11:41, Samuel Gougeon a écrit :
Le 15/01/2019 à 10:47, Antoine ELIAS a écrit :
Hello Samuel,

You are right, there is no overload for these new operators.
for || and &&, it seems to be OK, we can create new overloads like %x_gg_x ( || ) and %_hh_x ( && ) for example.

but for {} it would be difficult, cell creation accepts ALL types so how to detect and call overloads ?

You are right. This concatenator can't be overloaded. Let's document it in its forthcoming page.

Do you think that overloading for || and && could be ready for Scilab 6.0.2, to make Scilab 6.0 regular?

Antoine,

After our discussion in private mails continuing this thread, i would like to go on about this topic.
For the short term, that's to say Scilab 6.0.2,  clarifying the not-overloadable status of && and ||
is a good thing. This is proposed here: https://codereview.scilab.org/20703

To abstract our private discussion:
My initial public question was about making these symbols overloadable as all other ones,
without any specific meaning or processing.
However, your were thinking about overloading them by keeping their "shortcircuit" property.
Finally, you told me that if this is not possible, and that just adding && and || to the list of
overloadable symbols is not interesting and should not be done.

I don't really agree with this last point. Even if such a regularization is rather not a high priority,
it would be interesting anyway. Scilab 6.0 aimed to make Scilab more regular than Scilab<6.
I hope that this will hold as well for next 6.x releases, avoiding exceptions.

Keeping the "short-circuit" property for the overloads of && and || is not possible for two reasons:
  • As you noted, after a && b, the overload will need to receive b anyway. This requires that b is evaluated anyway before calling the overload.
  • The even stronger reason is that the criterion deciding if b must be evaluated  or not is necessarily part of the overload. So a must be sent to the overload, and since the overload won't be called another time to send b, b must be sent -- and so evaluated -- from the beginning, at the first call, even before deciding whether b is useful.
Not making the criterion about a part of the overload would mean that a is necessarily boolean. Then, the overload would stand only on b, and would be always named %b_hh_<btype>(a,b).
To me, this would be a too poor restricted implementation.

The intention to keep the "shortcircuit" property should be abandoned.
However, the overloading of both operators could be implemented in a special way, in order to diversify overloading possibilities.
How?
The overloading of all other binary operators is called according to the type of both left and right operands.
But for some custom operations, being able to call an overload for a op b only according to the type of a would be interesting.
When developing in Scilab language, it is possible to meet situations where some very similar code is able to process a op b for various types of b.
Presently, the only way to do so is to replicate the code of say %ta_op_s in %ta_op_i, %ta_op_sp, %ta_op_i,  etc, or at least define them and route to the same %ta_op_s().
This is not very smart.

So, the special implementation that we could imagine would be to call %typea_hh(a,b) only according to a's type.

This would make && and || of fractional multiplicity 1.5.
This would not be a shortcircuit, but this is currently the best thing i may propose to you and users about this topic.
; -)

Hoping to read other contributions,

Regards
Samuel


_______________________________________________
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: &&, ||, {} as cell-builder not overloadable: official?

Le 22/01/2019 à 19:12, Samuel Gougeon a écrit :
Le 15/01/2019 à 11:41, Samuel Gougeon a écrit :
Le 15/01/2019 à 10:47, Antoine ELIAS a écrit :
Hello Samuel,

You are right, there is no overload for these new operators.
for || and &&, it seems to be OK, we can create new overloads like %x_gg_x ( || ) and %_hh_x ( && ) for example.

but for {} it would be difficult, cell creation accepts ALL types so how to detect and call overloads ?

You are right. This concatenator can't be overloaded. Let's document it in its forthcoming page.

Do you think that overloading for || and && could be ready for Scilab 6.0.2, to make Scilab 6.0 regular?

Antoine,

After our discussion in private mails continuing this thread, i would like to go on about this topic.
For the short term, that's to say Scilab 6.0.2,  clarifying the not-overloadable status of && and ||
is a good thing. This is proposed here: https://codereview.scilab.org/20703

To abstract our private discussion:
My initial public question was about making these symbols overloadable as all other ones,
without any specific meaning or processing.
However, your were thinking about overloading them by keeping their "shortcircuit" property.
Finally, you told me that if this is not possible, and that just adding && and || to the list of
overloadable symbols is not interesting and should not be done.

I don't really agree with this last point. Even if such a regularization is rather not a high priority,
it would be interesting anyway. Scilab 6.0 aimed to make Scilab more regular than Scilab<6.
I hope that this will hold as well for next 6.x releases, avoiding exceptions.

Keeping the "short-circuit" property for the overloads of && and || is not possible for two reasons:
  • As you noted, after a && b, the overload will need to receive b anyway. This requires that b is evaluated anyway before calling the overload.
  • The even stronger reason is that the criterion deciding if b must be evaluated  or not is necessarily part of the overload. So a must be sent to the overload, and since the overload won't be called another time to send b, b must be sent -- and so evaluated -- from the beginning, at the first call, even before deciding whether b is useful.
Not making the criterion about a part of the overload would mean that a is necessarily boolean. Then, the overload would stand only on b, and would be always named %b_hh_<btype>(a,b).
To me, this would be a too poor restricted implementation.

The intention to keep the "shortcircuit" property should be abandoned.
However, the overloading of both operators could be implemented in a special way, in order to diversify overloading possibilities.
How?
The overloading of all other binary operators is called according to the type of both left and right operands.
But for some custom operations, being able to call an overload for a op b only according to the type of a would be interesting.
When developing in Scilab language, it is possible to meet situations where some very similar code is able to process a op b for various types of b.
Presently, the only way to do so is to replicate the code of say %ta_op_s in %ta_op_i, %ta_op_sp, %ta_op_i,  etc, or at least define them and route to the same %ta_op_s().
This is not very smart.

So, the special implementation that we could imagine would be to call %typea_hh(a,b) only according to a's type.

This would make && and || of fractional multiplicity 1.5.
This would not be a shortcircuit, but this is currently the best thing i may propose to you and users about this topic.

To illustrate on a case that many of us have likely already met:
When a custom operator supports 5 distinct data types for both operands,
only 5 overloads/files would then have to be defined, instead of 5x5  = 25 files...
The added value would be clear.

By the way, this kind of implementation could become generic, even for native operators:
if %typea_op_typeb() is not defined => test whether %typea_op(a,b) is defined, and call it if it's the case.

Samuel


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

Re: &&, ||, {} as cell-builder not overloadable: official?

In reply to this post by Samuel GOUGEON
Hello Samuel,

You know my point of view:
> The intention to keep the "shortcircuit" property should be abandoned.
Sorry I cannot be agree with that. b can be a non-idempotent code/function or a failing code ( isfield(st, "foo") && st.foo == x )
&& is often used to evaluate/execute or not "b".

"b" should not be evaluated until we know the result of "a".
If you don't care about short-circuit, use & or | instead of && or ||.


About generic version of overload %x_op(a, b), I guess that can be a good idea (in 6.1.0 ^^ ) but full version %t_op_t(a,b) must stay priority if exists.
That could reduce number of overloads that only reroute to %t_op_generic(a, b) for example.

Hoping to read other contributions too,
Antoine
Le 22/01/2019 à 19:12, Samuel Gougeon a écrit :
Le 15/01/2019 à 11:41, Samuel Gougeon a écrit :
Le 15/01/2019 à 10:47, Antoine ELIAS a écrit :
Hello Samuel,

You are right, there is no overload for these new operators.
for || and &&, it seems to be OK, we can create new overloads like %x_gg_x ( || ) and %_hh_x ( && ) for example.

but for {} it would be difficult, cell creation accepts ALL types so how to detect and call overloads ?

You are right. This concatenator can't be overloaded. Let's document it in its forthcoming page.

Do you think that overloading for || and && could be ready for Scilab 6.0.2, to make Scilab 6.0 regular?

Antoine,

After our discussion in private mails continuing this thread, i would like to go on about this topic.
For the short term, that's to say Scilab 6.0.2,  clarifying the not-overloadable status of && and ||
is a good thing. This is proposed here: https://codereview.scilab.org/20703

To abstract our private discussion:
My initial public question was about making these symbols overloadable as all other ones,
without any specific meaning or processing.
However, your were thinking about overloading them by keeping their "shortcircuit" property.
Finally, you told me that if this is not possible, and that just adding && and || to the list of
overloadable symbols is not interesting and should not be done.

I don't really agree with this last point. Even if such a regularization is rather not a high priority,
it would be interesting anyway. Scilab 6.0 aimed to make Scilab more regular than Scilab<6.
I hope that this will hold as well for next 6.x releases, avoiding exceptions.

Keeping the "short-circuit" property for the overloads of && and || is not possible for two reasons:
  • As you noted, after a && b, the overload will need to receive b anyway. This requires that b is evaluated anyway before calling the overload.
  • The even stronger reason is that the criterion deciding if b must be evaluated  or not is necessarily part of the overload. So a must be sent to the overload, and since the overload won't be called another time to send b, b must be sent -- and so evaluated -- from the beginning, at the first call, even before deciding whether b is useful.
Not making the criterion about a part of the overload would mean that a is necessarily boolean. Then, the overload would stand only on b, and would be always named %b_hh_<btype>(a,b).
To me, this would be a too poor restricted implementation.

The intention to keep the "shortcircuit" property should be abandoned.
However, the overloading of both operators could be implemented in a special way, in order to diversify overloading possibilities.
How?
The overloading of all other binary operators is called according to the type of both left and right operands.
But for some custom operations, being able to call an overload for a op b only according to the type of a would be interesting.
When developing in Scilab language, it is possible to meet situations where some very similar code is able to process a op b for various types of b.
Presently, the only way to do so is to replicate the code of say %ta_op_s in %ta_op_i, %ta_op_sp, %ta_op_i,  etc, or at least define them and route to the same %ta_op_s().
This is not very smart.

So, the special implementation that we could imagine would be to call %typea_hh(a,b) only according to a's type.

This would make && and || of fractional multiplicity 1.5.
This would not be a shortcircuit, but this is currently the best thing i may propose to you and users about this topic.
; -)

Hoping to read other contributions,

Regards
Samuel


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


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