constant for empty prefix set

[Alexander Zubkov]

On Wed, Feb 23, 2022, 17:43 Ondrej Zajicek <santiago at crfreenet.org> wrote:

> On Wed, Feb 23, 2022 at 03:46:53PM +0100, Alexander Zubkov wrote:
> > Updated patch. Again full and incremental.
>
> Thanks, will look at it.
>

Good. Give me know if some additional work on the patch is needed.


>
> > > One solution would be a global constant empty trie, so you can just set
> > > pointer to that. Alternative would be just have NULL like in T_SET,
> > > but that would mean to add several special cases to trie functions,
> > > so that is probably worse approach. The difference is that for that
> > > trees NULLs are naturally valid values, while tries have header.
> >
> > OK, created a global constant. There is a pointer to the memory pool
> > in the f_trie structure, but I believe it is not used in this case. It
> > may be even good to have it set to NULL for this constant in case
> > somebody tries to add elements to that trie.
>
> Agreed.
>
>
> > > > 5) When prefix set variable is assigned an empty set, it is promoted
> > > > to the T_PREFIX_SET, of course, but after that it becomes not equal
> to
> > > > "[]", because the type is different. But that can be considered a
> > > > feature, not a bug.
> > >
> > > Yes, if FI_EQ used ARG_SAME_TYPE(), the typecheck would force
> promotion,
> > > but our equality check accepts any pair of objects (and returns false
> > > for object of different types instead of failing).
> > >
> > > I will look into this by implementing some restricted variant of
> > > ARG_SAME_TYPE() that forces promotion but otherwise ignores mismatched
> > > types.
> >
> > The other possibility is to alter val_same()/val_compare() functions
> > to handle that situation like for quads. It just the matter of what
> > behaviour is more preferrable. Current patch has this variant
> > implemented taking into account that all empty prefix sets use the
> > same emtpy trie constant.
>
> Well, our plan is to remove all these explicit IP<->quad conversions from
> the code and keep just constant promotions, which are handled uniformly
> by the static type mechanism. They are still here just because it is minor
> backward incompatible change (as constant promotion just promote constants,
> while these coversions convert values). So we do not want to add more such
> exceptions.
>

Ok, I get it. Yes, than your variant with promotion is more preferable.
Fortunately this exception can be easily dropped from the patch or when
promotion is implemented.


>
> > But altering val_compare() will make the comaprison of typed variables
> > with empty sets to be true, for example prefix set with int set. On
> > the other hand, currently it does the same with different sets
> > represented as T_SET. And as I understand, it is also possible to
> > compare an ip set with a quad set.
>
> The fact that non-prefix sets all use T_SET and are not properly
> differentiated
> by different T_*_SET value is unfortunate limitation, but probably not
> worth
> fixing/handling now.
>

Yes, I do not see a big problem here either. As you said, tries to compare
types, which are different syntactically in the first place, looks strange
by itself. And can be prohibited at parse time if needed.


> If we turn away from sets to say *lists, we already have different values
> for empty clist / eclist / lclist (i.e. returning false for val_same()).
> If we ever implement proper literal constants for *lists, then these
> empty values would be represented by the same empty literal (instead of
> the current adhoc syntax).
>
>
> --
> 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/20220223/ea1416ca/attachment.htm>