Project to create a language definition in BNF format started

[darnocian 70]

I mentioned ANTLR before (https://www.antlr.org/). I'm just wondering if it would not be worth adopting a syntax like that that can be consumed and used in tooling instantly?

 

e.g. https://github.com/fabriciocolombo/sonar-delphi/blob/master/src/main/antlr3/org/sonar/plugins/delphi/antlr/Delphi.g (a version 3 grammar)

      https://github.com/gotthardsen/Delphi-ANTRL4-Grammar/blob/master/Delphi.g4

 

Unfortunately, there isn't a 'runtime' for delphi on the latest version which is very mature, but using another language run time, like java, c#, etc, we could easily make a simple parser for delphi, until someone has time to work on one for delphi.

Edited February 15, 2022 by darnocian

[Anders Melander 1635]

42 minutes ago, darnocian said:

that that can be consumed and used in tooling instantly?

Shouldn't that be "that can be consumed and used in a tool instantly"...?  or do you know of something other than ANTLR that consumes the ANTLR grammar?

[darnocian 70]

2 minutes ago, Anders Melander said:

Shouldn't that be "that can be consumed and used in a tool instantly"...?  or do you know of something other than ANTLR that consumes the ANTLR grammar?

 

My point was less about how many tools can consume it, but about having something that could actually be used at the end of the day. It could be anything, I just happen to like ANTLR more compared to lex/yacc and flex/bison, which I used to use in the old days.  

 

I'm not sure 100% of our objective - do we just want to have a text document (which is valuable in its own right), or do we want to have a grammar that can be consumed by a tool as well?

[Uwe Raabe 1879]

At the end it doesn't matter which norm we use to write that grammar in, as long as we provide ways to convert that to whatever a target tool expects. So if we decide to hop on e.g. ABNF, we should create a companion converter to at least BNF as a common denominator. 

[Bill Meyer 333]

And as a friend was fond of saying: The nice thing about standards is that we have so many from which to choose.

[TurboMagic 91]

Now you discussed this at length but it looks like no clear conclusion was reached yet and nobody seems to have done anything about this grammar. Looks like a grammar is not usefull at all... 😉

[David Hoyle 66]

If people can decide on the grammar to be used I can translate what I've put into the repository.

[David Champion 46]

24 minutes ago, David Hoyle said:

If people can decide on the grammar to be used I can translate what I've put into the repository.

I would prefer the Antlr grammar mainly because you can build and test the grammar as you go with the tools provided.

 

Also, there are some excellent books by Terrance Parr.

 

I could try and revive my Antlr StringTemplate for Delphi project if the repo went in that direction. 

 

 

 

 

[Uwe Raabe 1879]

41 minutes ago, David Hoyle said:

If people can decide on the grammar to be used

🤣 you nailed it!

[David Champion 46]

There has been some discussion in the past about whether is even possible to catch every valid grammar production using BNF or EBNF.

 

Because Object Pascal/Delphi compilers have used hand crafted parsers the language has evolved with some inconsistencies unchecked by formal grammars.

 

 

[Marco V 3]

19 hours ago, David Champion said:

I would prefer the Antlr grammar mainly because you can build and test the grammar as you go with the tools provided.

 

 

The problem is that while that philosophy works well with reasonably clean languages that were designed top down using a grammar, it often doesn't work very well to retrofit to languages that weren't, or have seen decades worth of ad-hoc expansion with attempts at backwards compatibility.

 

The delphi dialect is much more complicated then most people think. Note that if you get something working, you might want to try to push selected parts of the Free Pascal compiler test suite through it to iterate and harden the grammar against corner cases.

 

But one of the problems of grammar driven solutions is that you need to duplicate many rules for each exception making the grammar unworkable at some point.

 

Also, for something functional you often also need some form of semantic analysis, and Delphi has quite some implicit conversions (that then e.g. wreak havoc on e.g. overloading selection).

 

Edited March 3, 2023 by Marco V