constant for empty prefix set

[Ondrej Zajicek]

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.


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.

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