On Fri, Jun 23, 2023, 18:30 Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Wed, Jun 14, 2023 at 12:40:47AM +0200, Alexander Zubkov wrote:
> Hi,
>
> Please look at these patches:
>
> bytestring-hex-prefix.patch - syntax with "hex:" prefix
> I allowed mixed colons with no-divider there, so hex:12:345678:90 is
> allowed. As there is a distinguishing prefix here, this should not be
> a problem.
> Empty bytestrings are allowed too: "hex:"

Hi

Merged:
https://gitlab.nic.cz/labs/bird/-/commit/65d6a525944faa3f77041419991d77106d8f0a0d

I have mixed opinion on mixed colons here :-)


> bytestring-hex-function.patch - function-like hex("...") syntax (on
> top of the other patch)
> It wasn't too complex, but you might have wanted to do it some other
> way.

Yes, the original idea there was to add bytestring as a data type, make
hex() a regular (filter) function instead of special function-like
syntax, and add equivalent of 'expr' grammar term for other data types.

I see. I think I can look into preparing a patch for that too.
But for such variant I would suggest using function names like "from_hex/base64" instead of "hex/base64", or something including bytestring reference: "bs_hex". Because the simple variants could be misleading when used not only in the limited set of scopes. For example they can be thought of converting to hex/base64 representation too. Or they could collide with "hex" function to convert from string to int, which someone would need to implement in the future.



> I think this should be quite good too, the only problem with it
> is inability to mix "hex" symbol with hex("...") bytestrings.

This is an issue with any keyword, so not a big thing.

Yes. By the way what do you think about the patch that allows using keywords and symbols together? Is it viable?



> There probably was a mistake in nest/config.Y with missing "|" here:
> "kw_sym: MIN MAX ;"

You are right there.


> I also enabled TEXT literals to be multiline. Didn't know it was not
> allowed already, so I think it should not break things, but allows to
> be more flexible with binary strings.

That is probably right.


--
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago@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."