public inbox for ~johnnyrichard/olang-devel@lists.sr.ht
 help / color / mirror / code / Atom feed
From: ricardo_kagawa@disroot.org
To: ~johnnyrichard/olang-devel@lists.sr.ht
Subject: Re: [PATCH olang v1] spec: ebnf: add binary expressions
Date: Tue, 16 Apr 2024 20:17:15 -0300	[thread overview]
Message-ID: <20240416231715.51062-1-ricardo_kagawa@disroot.org> (raw)
In-Reply-To: <52aqozoevpqhucq67znjjbaqrpb65tubgc3yrp7isqo2x2bofz@ugtgrccjdkbb>

- This patch is missing the `%` operator;
- This patch seems to be missing the `>=` and `<=` operators.

> I'd like to get your opinion: Is it really necessary to represent
> precedence here? Some language specifications [1] chose to omit this

My opinion is that there are trade-offs to consider before deciding for
either convention or anything in-between. I suspect these are the
trade-offs to consider:

1. Implement precedence as part of the parser or as part of semantic
analysis;
2. Document precedence as part of the grammar or as a comment about the
grammar.

For the first item, if precedence is represented in the grammar, it
might be possible to evaluate expressions in the correct order during
parsing. Otherwise, the grammar is still valid, but semantic analysis
must find the correct order of expressions after parsing. The grammar
may be made simpler, but the complexity does not really go away.

For the second item, if precedence is represented in the grammar, you
don't have to define it authoritatively somewhere else (you may have
other informational documents describing that same precedence), so it is
automatically up-to-date. Otherwise, the grammar can be made simpler,
but it must refer to somewhere else to clarify what the precedence is,
which has to be updated separately.

Since the grammar is not used to generate the parser, there is less
benefit to representing precedence in the grammar. Still, I'd prefer to
represent it in the grammar, since I'm already familiar with that
convention, which might be the case for many other people and perhaps
even tools.

What really matters is that you are able to convey your intentions in
regards to language design, so that everyone from devs to users have a
close enough understanding to properly implement, use and reason about
it. Whatever you feel is clear enough for most people should be good
enough.

  reply	other threads:[~2024-04-16 23:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-15 18:20 Johnny Richard
2024-04-15 17:43 ` [olang/patches/.build.yml] build success builds.sr.ht
2024-04-16  3:33 ` [PATCH olang v1] spec: ebnf: add binary expressions Carlos Maniero
2024-04-16 19:20   ` Johnny Richard
2024-04-16 23:17     ` ricardo_kagawa [this message]
2024-04-18 23:17       ` Johnny Richard
2024-04-16 23:41 ` Johnny Richard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240416231715.51062-1-ricardo_kagawa@disroot.org \
    --to=ricardo_kagawa@disroot.org \
    --cc=~johnnyrichard/olang-devel@lists.sr.ht \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.johnnyrichard.com/olang.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox