Add formal EBNF syntax for Flint

[vietlq]

References from JSON:

• https://en.wikipedia.org/wiki/Extended_Backus–Naur_form
• https://www.json.org
• https://github.com/cierelabs/yaml_spirit/blob/master/doc/specs/json-ebnf.txt

I can help with this one :) It will be very useful for have formal EBNF syntax specification as we can use that to develop independent implementations. I want to develop one in JS or ReasonML/OCaml and compile to JS and then have a similar playground like Remix https://remix.ethereum.org or https://reasonml.github.io/en/try.html for people to learn & deploy quickly.

Developing a parser and syntax highlighter for Flint in JS would be a piece of cake when using this tool: https://nearley.js.org

Use this tool for syntax diagram generation: http://www.bottlecaps.de/rr/ui

[franklinsch]

The Flint grammar is specified here:
https://github.com/franklinsch/flint/blob/master/docs/grammar.txt

It's not exactly EBNF, but close.

[vietlq]

Nice. I will convert to EBNF and play with Nearley to parse the current files :)

[franklinsch]

Flint compiles to IULIA bytecode, which can be embedded in a Solidity file.
As described in the Language Guide, Flint code can already be used in Remix and with Truffle already.

However, features such as line-by-line debugging wouldn't be possible. I'm not a fan of compiling Flint to JS. Rather than building a web-based IDE/playground, I think a binary application is better suited for debugging. It would allow to interact with the bytecode itself (which is what will actually be deployed to Ethereum), rather than a JS version—which is not guaranteed to be equivalent to the bytecode.

[franklinsch]

Please make a PR once you have an EBNF! :)

[vietlq]

Sure. Just to clarify, I won't compile Flint to to JS code, but rather try to use Remix & use bytecode for maximum compatibility. Do you have link to IULIA bytecode? I googled but instead found Julia lang.

[franklinsch]

Hmm, so you would still like to reimplement the compiler? What is the purpose of that?
IULIA documentation is available here: http://solidity.readthedocs.io/en/v0.4.23/julia.html
IULIA was renamed from JULIA.

[vietlq]

Thanks for the link. I will start with EBNF first. I'm not very familiar with Swift. As Flint is still fresh, I think that having a tool to convert Solidity to Flint would be more useful than writing a new Flint compiler at the moment :) When the language is more mature, I think then we could have another Flint compiler implementation. I would be happy to learn more about Swift and contribute to the project :)

[franklinsch]

Swift is easy to pick up, and its type system has some nice features—which a lot of my OCaml friends like. I'd recommend trying it out! A Solidity to Flint compiler would be useful but I think would be challenging!

I'm glad you'd like to contribute to the Flint compiler! I think a good start issue would be #116. Let me know if I can help!

[vietlq]

Hehe, you are right. I realised Flint compiles to Solidity and compiling Solidity to Flint is going backward. It won't be possible until standard library, structs in Solidity are done properly.

[vietlq]

@franklinsch What is branch-statement? Thanks. Also I found that generic-argument-list should be generic-parameter-list

// Statements

statements -> statement (statements)
statement -> expression
statement -> [return] (expression)
statement -> branch-statement

[franklinsch]

branch-statement should be if-statement, and you are right about generic-argument-list. I think the other way around is better though, i.e. generic-parameter-list should actually be generic-argument-list.

Thank you for spotting that! Please feel free to submit a PR, otherwise I can do it as well.

[vietlq]

Sure I will create a PR :)

[vietlq]

I have a few questions:

• What's the delimiter between the statements? \n and \r\n? It's quite unclear from statements -> statement (statements)
• Do you plan to have keywords for built-in types like uint/uint256/bytes32 ... etc?
• Do parentheses in the grammar.txt mean optional? See: (else-clause)

Thanks.

[vietlq]

So as we discussed in #192

variable-declaration -> "var" identifier type-annotation ("=" expression)

Should be changed to:

variable-declaration -> "var" identifier type-annotation "=" expression

That's only for dynamic variables, not for properties that can be initialised in the init()

[franklinsch]

The delimiter between statements in \n. Although I believe the compiler supports \r\n, too. If you have arguments as to why it should be \r\n, I'd be happy to hear them.

Low-level types will not be accessible by the user directly. They can be dangerous to use. Flint's Int type will have safe wrap-around semantics.

Yes, the parenthesis mean optional.

Hope that helps!

[franklinsch]

I replied in #192 :)

[vietlq]

Thanks. I will support both \n and \r\n. There are too many Windows to ignore ;)

[vietlq]

Please enlighten me more about Flint Int built-in type and how they can provide safety compared to myriads of uintXX? Thanks :D

[franklinsch]

Adding very large uintXX values together can silently cause an integer overflow. This was an issue in many smart contracts. There's a thread about it on the Solidity side: ethereum/solidity#796

In Flint, an exception should be thrown on overflow. There should be a &+ operator, which would preserve the wrap-around semantics, like Swift has: https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/AdvancedOperators.html#//apple_ref/doc/uid/TP40014097-CH27-ID37

This is tracked by #193.

[vietlq]

Work is being done slowly here: https://github.com/vietlq/flint/tree/scratch/add-nearley-parser