Some additional ideas for decorating binary strings so that they do
not resemble other statements:
@hex(...)
bin:hex(...)

BTW, if we put a string literal inside the brackets, we can mimic a
function call without dirty lexer/parser hacks:
hex("...")

Or maybe you have already agreed on something?


On Mon, Jun 12, 2023 at 4:02 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:

 On Mon, Jun 12, 2023 at 03:32:20PM +0200, Maria Matejka wrote:
 We can simply change the lexer state externally from the parser as soon as the hex( prefix is seen, and provide the result directly from the lexer.

 This way, we can allow all the syntaxes like hex(de-ad-be-ef), hex(de:ad:be:ef), hex(de ad be ef) or even hex(dea:db-eef) just by ignoring nonalnum characters altogether.

 Here I'd strongly prefer nicer user experience over setting the syntax to best fit our needs.

 Which would lead to syntax that is extremely confusing (i.e. hard to
 intuitively grasp the right mental model just from meeting examples),
 so i think hex(...) variant is also worse from user experience point.
 As a user, i always hated unexpected special cases in syntax, even if
 they might be expedient in some cases.

I don't think any user really cares about the lexer/parser difference.

 People came with some preconceptions based on knowledge of syntax of
 other programming / configuration (and also regular) languages, so they
 have (either explicit or intuitive) concept of elementary / compound
 statement. If there is someting that looks like existing compound
 statement, but is in fact something completely different, it is
 confusing.

 --
 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."