Re: [RFC PATCH olang v1] docs: create zero programming language specification

[Johnny Richard <johnny@johnnyrichard.com>]

Amazing job. Wonderful changes and thank you so much for you
contribution.

On Fri, Mar 15, 2024 at 05:54:10PM -0300, Ricardo Kagawa wrote:
> > You've replied to the CI build reply.  Next time try to reply to the
> > right thread.
> 
> I just opened the "Reply to thread" link from sourcehut's web interface.
> It automatically filled the TO, CC, Subject and some thread ID header,
> which values I just trusted. It seems the UI is not to be trusted, but
> then, which values should I use? The address in TO seems to have bounced
> my reply, so I thought it didn't even make it to sourcehut.

Sad to hear the Sourcehut reply is miss behaving.  Could you please
report the problem to them?

The good practice is always **reply all** (in case someone who is not
subscribed to the mailing list can follow up the thread discussion).
Since I wrote the email you replied, you should reply it to me and
**CC** the mailing list and carry the **CC** from previous Email (reply
already behaves like so).  You might want to have a copy (optional), in
that case you can **BCC** yourself.

In order to have set up correctly the thread you want to reply to, you
have to set the **In-Reply-To** header with the **Message-ID** of the
message you want to reply to.

It seems to be very hard to active but your email client should do the
work.  You can download and import the email thread from the archive
right into your email client and **reply all**. 

There is another mailing list archive[1] which has instruction on how to
reply to emails using **git-send-email** that maybe you might be interested.

[1]: http://lists.johnnyrichard.com/olang/

For example, you could follow the steps bellow to reply to the right
thread using **git-send-email**:

    Reply instructions:

    You may reply publicly to this message[2] 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[3]

      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=y2brhif5vjjbjmd26wwxykhlt2qnnm2k7n2lpiz7dr7pccmoc7@qqx67mvyzl2c \
        --to=johnny@johnnyrichard.com \
        --cc=ricardo.kagawa@gmail.com \
        --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[4]

    Be sure your reply has a Subject: header at the top and a blank line before the message body. 

[2]: http://lists.johnnyrichard.com/olang/y2brhif5vjjbjmd26wwxykhlt2qnnm2k7n2lpiz7dr7pccmoc7@qqx67mvyzl2c/#t
[3]: http://lists.johnnyrichard.com/olang/y2brhif5vjjbjmd26wwxykhlt2qnnm2k7n2lpiz7dr7pccmoc7@qqx67mvyzl2c/raw
[4]: mailto:johnny@johnnyrichard.com?In-Reply-To=%3Cy2brhif5vjjbjmd26wwxykhlt2qnnm2k7n2lpiz7dr7pccmoc7@qqx67mvyzl2c%3E&Cc=ricardo.kagawa%40gmail.com%2C~johnnyrichard%2Folang-devel%40lists.sr.ht&Subject=Re%3A%20%5Bolang%2Fpatches%2F.build.yml%5D%20build%20success

> > Your message has few weird line breaks.
> 
> I am not myself sure, but I suspect it is an issue with the file format
> generated by `vim`. My default `email` file type seems to be forcing the
> `dos` format (CRLF line breaks), which might be being interpreted as two
> separate line breaks somewhere between Thunderird, Gmail and sourcehut.
> I'll see if I can force it to use the `unix` format (LF only) and if
> that fixes things at all.

I think you made it, this email looks good.  Perhaps you can set the vim
as your default editor on Thunderird (I know you can do it but not sure
how). Gmail should not mess up with you message.

If you like to live on terminal I suggest **mutt** or **aerc** clients
which works out of the box with plain text emails and they are very flexible.

> > I'm not sure how you want to version lock this variant.  Should I add
> > a specific github/git tag version to the document?
> 
> Yes, sort of. The web tool itself cannot be version locked, since it
> simply does not have that option, but it does link to its GitHub
> project. The project does not itself contain the description of its
> EBNF syntax, but it does have a link to what it uses to implement its
> EBNF parser, which in turn describes its syntax. You could include a
> version locked link to [that][1].
> 
> [1]: https://github.com/Engelberg/instaparse/tree/v1.4.12

Sounds good.

> > > Is the language going to support Unicode?
> > 
> > I would say to keep it simple as much as we can on this earlier stage
> > (ASCII only) unless you have a big concern.
> 
> I guess that would be OK. I don't think it would be too difficult to
> migrate later. Maybe tricky, but not difficult, since Unicode is a
> superset of ASCII. Just need to be careful not to depend too much on
> the fact that ASCII characters are stored in 8-bit variables, as
> Unicode uses variable-length characters (variable within a string, but
> characters are multiples of 8 bits).

Nice, let us know whenever we make such ASCII dependency. 

> > If we don't add a token in here like **=** it will be very weird.
> 
> Actually, I mentioned Kotlin also to imply that there would be an
> equals sign before the expression.
> 
> > > - I have not checked if this syntax would avoid that edge case with
> > >   JavaScript I mentioned in the beginning. I might check that next
> > >   time (I'm still not sure of how).
> > 
> > Maybe we are going to discovery it on the implementation process.
> 
> I _suspect_ it would be enough to give precedence to interpreting line
> breaks as end-of-statement, and if so, there might be a way to represent
> that precedence in the EBNF grammar (by convention). I would still need
> to mull over it for a while to be sure.

I can test the precedence solution later as well.

> Another revision:
> 
> - Function body now accepts a single expression.

Hmm... I think we still haven't agreed on having it.  We are trying to
make a very simple language and maybe avoid having multiple ways of
achieving the stuff will make it simpler.

> - Introducing hexadecimal integer literals.
>     - Hexadecimal literals are allowed to have an arbitrarily long
>       sequence of zeroes to the left, after the `0x` prefix. This is
>       intentional, and the parser should ignore excess zeroes.
>     - The alphabetic characters in the literal should be parsed without
>       case-sensitivity. There is no difference between the `0x` and `0X`
>       prefixes in literals. If mixed case is not desirable, let the
>       linter or formattter restrict that.

Nice you added support to hex. We will need octal in the future as well
(starting with 0).  But let's craft more features in new patches, this
thread is become out of control.  Perhaps we can merge an initial
version and propose small changes to it (making new discussion threads).

I can set up a PATCH with most of your changes (except the function
definition with single line, we can discuss it on a new PATCH thread).