On Fri, Jun 23, 2023, 18:30 Ondrej Zajicek <santi...@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: santi...@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." >
