On Sat, Jun 24, 2023 at 02:20:03AM +0200, Alexander Zubkov wrote:
> > 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.
> 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.
Yes, that is true.
You can try it if you are brave enough to add new f_val type.
> > > 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?
Answered there.
--
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."
