constant for empty prefix set

Alexander Zubkov green at qrator.net
Tue Feb 22 03:02:55 CET 2022


On Tue, Feb 22, 2022, 01:21 Ondrej Zajicek <santiago at crfreenet.org> wrote:

> On Mon, Feb 21, 2022 at 11:01:25PM +0100, Alexander Zubkov wrote:
> > Made some example changes to allow the use of an empty set, which
> > works with all types and prefixes too. Its value has type T_SET with
> > NULL pointer to the tree. Looks goot at the first sight.
>
> Hi
>
> Is assigning [] to variable of 'prefix set' type or function argument
> working properly?
>
> Note that global constants do not have type declaration, but variables
> and function arguments have.
>

Good points. Will check that. Thanks.


>
> 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?


> --
> 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."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20220222/cfa62425/attachment.htm>


More information about the Bird-users mailing list