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: santi...@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."
