Re: [olang/patches/.build.yml] build success

[Johnny Richard <johnny@johnnyrichard.com>]

Thank you very much for you contribution, I love it <3.

nitpick for next replies:

    1) You've replied to the CI build reply.  Next time try to reply to
       the right thread.

    2) Your message has few weird line breaks.  I don't know why it's
       happening (noticed you are using Thunderbird).  However, you can
       make sure your setup is correctly configured to send plain text
       emails by visiting this website https://useplaintext.email/

On Thu, Mar 14, 2024 at 01:29:09AM -0300, Ricardo Kagawa wrote:
> >> This grammar adds the token SEMICOLON (';') for every statement.  I know
> we
> >> agreed make it optional, but the SEMICOLON makes the parser much more
> >> convenient to implement.
> >>
> >> And this is the first topic I would like to discuss. Let me know if you
> >> agree otherwise I can adapt the grammar to make SEMICOLON optional.
> >
> > (...) Therefore, I'm curious about your statement that using a
> > semicolon makes the parser much more convenient to implement. Could you
> > elaborate on this? Have you encountered any new considerations that might
> > complicate the implementation?
> 
> My limited understanding is that the semicolon would indeed be more
> convenient, as it would be a definitive end-of-statement symbol,
> requiring no lookahead to resolve as such. The LF token could be
> ambiguous on its own (between end-of-statement and white space), so
> some lookahead would be required to resolve it.

You are right about it.  I had to implement the lookahead capability in
order to skip LF tokens.

> But it should be alright, as long as the language remains context-free.
> Even if it becomes ambiguous, non-deterministic, or requires a long
> lookahead. Ideally it should be determinitstic for linear time
> performance, but it seems there are parsers that can run close to it in
> the average case, as long as the language remains close to
> deterministic.
> 
> And I don't have a strong opinion on the semicolon issue, except that
> it must be an option. But whatever we do, we must avoid the following
> pitfall from JavaScript:
> 
> ```javascript
> example
> ;(x)
> ```
> 
> The semicolon is mandatory here, because otherwise `(x)` is handled as
> an argument list, and `example` would be called as a function. That is,
> it would be a multi-line statement, instead of two separate statements.
> 
> And why anyone would do this?
> 
> ```javascript
> const x = y.example
> ;(() => {
>   console.log(x)
> })()
> ```

I strong agree on avoid those odd JavaScript design.  I think we can
continue with optional SEMICOLON.  I also think it makes a better
programmer experience.

> >> The grammar was made by using a EBNF evaluator tool[1].
> >>
> >> [1]: https://mdkrajnak.github.io/ebnftest/
> >
> > I would add this link at the markdown, so then people can play with it.
> 
> I would make an even stronger argument for including the link in the
> docs. A good language specification also specifies which language
> specification grammar is used for the specification itself. And the
> EBNF in particular is not properly standardized, so you really need to
> specify which EBNF variant you are using.
> 
> The link should thus be good enough to refer to the EBNF implementation
> used in this specification, although a permanent (version locked) link
> would be better.

Sure, I can add it to the document.  I'm not sure how you want to
version lock this variant.  Should I add a specific github/git tag
version to the document?

> As for my revision of the grammar:

I liked all comments and definitely it seems to be better version.  In
my option we can start with you changes and keep this document alive for
future discussion.  Not sure about Carlos.  Let see his thoughts on that
as well.

> Further discussion:
> 
> - Is the language going to support Unicode? If so, `<alpha>` could use
>   the _L:Letter_ Unicode category instead of being limited to
>   `[a-zA-Z]`. But the EBNF tool does not support Unicode categories in
>   its regular expressions (it does not support flags). Also don't
>   forget to rename it to `<letter>` in that case.
> 
>     - It would help developers in non-English speaking countries, but it
>       could be difficult to work with multi-byte characters and Unicode
>       normalization.

I lack knowledge to answer this question right know.  I would say to
keep it simple as much as we can on this earlier stage (ASCII only)
unless you have a big concern.

> - There are more linear space and line break characters than the ones
>   included here, even within ASCII, although they are not all that
>   important. Even more in Unicode (some under _Cc:Other/control_,
>   others under _Z:Separator_). Should we support them?

Let's add the remaining ASCII ones meanwhile.

> - The function definition could accept a single expression as an
>   alternative to its `<block>`, similar to Kotlin.

Scala also has this capability.  But I think it doesn't fit well in our
current function declaration:

    fn f(): u32 <statement>
               ^
               If we don't add a token in here like **=** it will be very
               weird.

No strong options here to be honest.

> - The integer literal could include optional underline separators for
>   readability. Just need to be careful not to start with underline, to
>   avoid ambiguity with identifiers.

I like that.  We can have it as well.

> - I guess we don't have to support the full set of Unicode digits, since
>   we don't know if these digits would even be decimal in the first
>   place. The numbering system could be very different from our own, so
>   it is likely not feasible to support them.

Perhaps we could postpone the Unicode support?

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

> - It might seem strange that I included semantic non-terminals here,
>   despite having removed non-terminals for symbols and keywords. I can't
>   say for sure, since this is my first time trying this style, but I
>   suspect that besides making the language specification easier to
>   understand, the important bits to hook into in the parser will be
>   around these symbols. That is, it could simplify some work on the
>   parser.

ACK