constant for empty prefix set

[Alexander Zubkov]

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 could be a separate type (for example T_EMPTY_SET) or a set (T_SET)
with an empty tree. I can try to prepare patches for that if you want.

On Mon, Feb 14, 2022 at 11:46 PM Alexander Zubkov <green at qrator.net> wrote:
>
> On Mon, Feb 14, 2022 at 9:47 PM Ondrej Zajicek <santiago at crfreenet.org> wrote:
> >
> > On Thu, Feb 10, 2022 at 02:09:59PM +0100, Alexander Zubkov wrote:
> > > Hi,
> > >
> > > Let me remind about this once again.
> >
> > Hi
> >
> > Sorry for ignoring your previous mail, i needed to focus on finishing
> > things for 2.0.9, now i can continue with your patches.
>
> Thank you, looking forward to it!
>
> >
> > 1) UDP logging - I have no principal issue with this, will review and merge.
> >
> > 2) Keeping proto state during reconfiguration - I am ok with 'configure keep'
> > patch, will preview and merge. I do not want 'keep state' per-protocol
> > option. Perhaps also some 'configure xyz' for regular configure and some
> > global option how 'configure' without arguments should behave for people
> > who would like 'configure keep' to be the default behavior.
> >
> > 3) prepend_times() - I am a bit ambivalent about that. I see usefulness
> > of that. I do not like the name. It can be implemented as optional
> > argument to prepend(), but not sure if that is better. Will think about
> > that. Also, considering user mistakes like [*], we perhaps should
> > limit multiplier by say 16.
>
> I do not insist on the name of course, or implementation. :)
>
> >
> > [*] https://bgpmon.net/long-as-paths-causing-commotion/
> >
> > 4) Empty prefix set - Too hacky and inconsistent syntax. Note that there
> > are also non-prefix sets. We already have ugly hacks for empty community
> > lists, we want to avoid yet another way to define empty structures.
>
> Yes, I know about other sets, that is why I choose how to name this
> set. But probably not completely the same:
> /empty/ vs [ /empty/ ]
> I did not know there was an intention to get rid of those hacky names,
> but on the other hand they need to be defined somehow and just using
> "[]" does not work because it is ambiguous for the parser. I do not
> insist on the name here, of course, just on the idea itself.
> Possibility to define an empty prefix set is indeed useful. If I match
> network against some named set, than I have no variants now how to
> define such set to be empty (or I do not know about such variant). If
> such set is defined separately, for example dynamically, sometimes I
> want it to be empty, so nothing would match it.
>
> >
> > Unfortunately there is no easy way to define literals that could be used
> > for multiple data types. We already have A.B.C.D, that could be both IP
> > address and router ID, and it is super annoying in the code. We would
> > like to have some more generic solution, we will think about that.
>
> Yes, I understand. Generic solution of course makes things clearer.
> But in this case even if we have some means to specify that ip-like
> literal is actually of type ip or quad, anyway it would be not so good
> to force everybody to specify types for all ip-like literals in their
> configs.
>
> As for generic way to define empty sets/list, I can imagine now these
> variants for consideration:
>
> function-like:
> emtpy_list(<type>), empty_set(<type>) - example: empty_set(ip),
> empty_list(lc), ...
> empty(<type>) - example: empty(ip set), empty(lclist)
>
> type-conversion-like:
> (<type>) [] - example: (ip set) [], (lclist) []
>
> OO-like:
> type.<type>.empty - type.ip_set.empty, type.lclist.empty
>
> >
> > 5) Reduce/reduce fix - Will look at this.
> >
> >
> > > On Tue, Jan 11, 2022 at 1:10 PM Alexander Zubkov <green at qrator.net> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Let me ping this. I would like to receive a feedback on this (and some
> > > > other my recent) messages.
> > > >
> > > > On Sat, Jan 1, 2022 at 9:45 PM Alexander Zubkov <green at qrator.net> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I propose to add some constant for empty prefix set, for example (as
> > > > > in the patch):
> > > > > define pfx_empty = [ /empty/ ];
> > > > >
> > > > > It is useful when we define a named prefix list, which we can use
> > > > > somewhere in filters, but this prefix list is generated, for example,
> > > > > and we may need to make it empty. But there is no currently means to
> > > > > create an empty prefix set, as I understand.
> >
> > --
> > 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."