Well, we haven't agreed yet. We're gonna meet tomorrow so there may be a
discussion about this in person and then we'll come with some agreement.
Anyway, thank you for all the input!
Maria
On 12 June 2023 17:55:34 CEST, Alexander Zubkov <gr...@qrator.net> wrote:
>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."
--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
