On Tue, Feb 22, 2022 at 03:02:55AM +0100, Alexander Zubkov wrote:
Also to your previous question:
I also think now - why at all do we need a typed empty set? I think it is possible to add an untyped empty set, that will act as a "joker" with any types. It should fit better to the current syntax now without introducing a lot of new constructions.
It breaks static type controls or at least make them more complicated. Note that our types for sets are already pretty broken - we have just T_SET and T_PREFIX_SET in implementation, although different types of sets are used in filter language (e.g. 'int set' in variable definition) and matching types are tested just in runtime (based on set->from.type). But let's assume we would fix this, we would have types T_INT_SET, I_IP_SET, ..., T_PREFIX_SET for each set type.
Then defining untyped empty set means it would be a new type (T_EMPTY_SET) different from others, it would require some exceptions in type checks (e.g. FI_VAR_SET just checks that type of value is the same as type of variable) and many expressions that accepts or returns value of just one type now would accepts or returns values of two different types. We would have to extend type checking system for this or implement some concept of subtyping or type coercion.
Sure, I had the same concerns about this idea with T_EMPTY_SET. But on the other hand, with an empty T_SET we still need to make an exception at least for prefixes. And if, as you said, there are more types of sets in the future, than there will be still more exceptions. So in some circumstances, I think, both ways will have around the same number of exceptions. But currently, the empty T_SET looks easier of course.
So, are you against an untyped empty set constant given the mentioned problems? Or you are unhappy about the complexity of implementing and maintaining that idea, but anyway consider it acceptable?
I checked how IP/QUAD situation is solved and it is cleaner than i thought. There is already constant promotion function f_const_promotion() that can be extended to handle empty sets. So seems to me that with the current state of BIRD code this is simplest approach: There should be two empty sets values, one for T_SET (which behaves like in your patch) and one for T_PREFIX_SET (which would be just empty trie). Constant [] would generate the T_SET empty constant, but f_const_promotion() would handle promotion of T_SET empty constant to T_PREFIX_SET empty constant when needed. That should fix issues with variables/arguments. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."