<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 22, 2022, 01:21 Ondrej Zajicek <<a href="mailto:santiago@crfreenet.org">santiago@crfreenet.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Feb 21, 2022 at 11:01:25PM +0100, Alexander Zubkov wrote:<br>
> Made some example changes to allow the use of an empty set, which<br>
> works with all types and prefixes too. Its value has type T_SET with<br>
> NULL pointer to the tree. Looks goot at the first sight.<br>
<br>
Hi<br>
<br>
Is assigning [] to variable of 'prefix set' type or function argument<br>
working properly?<br>
<br>
Note that global constants do not have type declaration, but variables<br>
and function arguments have.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Good points. Will check that. Thanks.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Also to your previous question:<br>
<br>
> > I also think now - why at all do we need a typed empty set? I think it<br>
> > is possible to add an untyped empty set, that will act as a "joker"<br>
> > with any types. It should fit better to the current syntax now without<br>
> > introducing a lot of new constructions.<br>
<br>
It breaks static type controls or at least make them more complicated.<br>
Note that our types for sets are already pretty broken - we have just<br>
T_SET and T_PREFIX_SET in implementation, although different types of<br>
sets are used in filter language (e.g. 'int set' in variable definition)<br>
and matching types are tested just in runtime (based on set->from.type).<br>
But let's assume we would fix this, we would have types T_INT_SET,<br>
I_IP_SET, ..., T_PREFIX_SET for each set type.<br>
<br>
Then defining untyped empty set means it would be a new type (T_EMPTY_SET)<br>
different from others, it would require some exceptions in type checks<br>
(e.g. FI_VAR_SET just checks that type of value is the same as type of<br>
variable) and many expressions that accepts or returns value of just one<br>
type now would accepts or returns values of two different types. We would<br>
have to extend type checking system for this or implement some concept of<br>
subtyping or type coercion.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- <br>
Elen sila lumenn' omentielvo<br>
<br>
Ondrej 'Santiago' Zajicek (email: <a href="mailto:santiago@crfreenet.org" target="_blank" rel="noreferrer">santiago@crfreenet.org</a>)<br>
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, <a href="http://wwwkeys.pgp.net" rel="noreferrer noreferrer" target="_blank">wwwkeys.pgp.net</a>)<br>
"To err is human -- to blame it on a computer is even more so."<br>
</blockquote></div></div></div>