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 <santi...@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: 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."
