constant for empty prefix set

[Ondrej Zajicek]

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 at 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."