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/65d6a525944faa3f77041419991d77106d8...
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."