Grammar railroad diagram

[mingodad]

Using the syntax described here https://dusa.rocks/docs/language/syntax/ after small fixes (<builtin-identifier> probably is <builtin>) I've included it here https://mingodad.github.io/parsertl-playground/playground/ (an Yacc/Lex compatible online interpreter/editor, select Gusa parser from Examples then click Parse to see a parser tree for the content in Input source) and from there generated the EBNF understood by https://github.com/GuntherRademacher/rr that generate a nice navigable railroad diagram that can be viewed online (see instructions at the top bellow).

//
// EBNF to be viewd at
//    (IPV6) https://www.bottlecaps.de/rr/ui
//    (IPV4) https://rr.red-dove.com/ui
//
// Copy and paste this at one of the urls shown above in the 'Edit Grammar' tab
// then click the 'View Diagram' tab.
//

program::=
	  program declaration
	| /*%empty*/

declaration::=
	  "#builtin" builtin identifier dot_opt
	| "#lazy" identifier dot_opt
	| "#demand" premises '.'
	| "#forbid" premises '.'
	| conclusion '.'
	| conclusion ":-" premises '.'

dot_opt::=
	  /*%empty*/
	| '.'

premises::=
	  premise
	| premises ',' premise

premise::=
	  term oper term
	| attribute
	| attribute "is" term

oper::=
	  "=="
	| "!="
	| ">="
	| '>'
	| "<="
	| '<'

conclusion::=
	  attribute
	| attribute "is" term_or_choices
	| attribute "is?" term_or_choices

term_or_choices::=
	  term
	| '{' choice_options '}'

choice_options::=
	  term
	| choice_options ',' term

attribute::=
	  identifier
	| identifier arguments

arguments::=
	  atomic_term
	| arguments atomic_term

atomic_term::=
	  wildcard
	| variable
	| string_literal
	| int_literal
	| identifier
	| builtin
	| '(' term ')'

term::=
	  atomic_term
	| identifier arguments
	| builtin arguments

builtin::=
	  "BOOLEAN_TRUE"
	| "BOOLEAN_FALSE"
	| "NAT_ZERO"
	| "NAT_SUCC"
	| "INT_PLUS"
	| "INT_MINUS"
	| "INT_TIMES"
	| "STRING_CONCAT"

//Tokens

COMMENT ::= "#"[ #x09].*
variable ::= [A-Z][a-zA-Z0-9_]*
wildcard::= '_'[a-zA-Z0-9_]*	 // and represents variable names that you wish to be ignored.
identifier ::= [a-z][a-zA-Z0-9_]*
string_literal ::= '"'[^"]+'"'	 //is a regular string constant with no escape characters: two double quotes " surrounding any ASCII character in the range 32-126 except for " and \.
int_literal ::= '0'|'-'?[1-9][0-9]*

[mingodad]

I think that calling the grammar in https://dusa.rocks/docs/language/syntax/ as Context-free grammar it's no true because you have <declaration> ::= "#builtin" <builtin> <identifier> [ "." that makes it a Context-sensitive grammar.

[spencerflem]

<builtin-identifier> probably is <builtin>

i've been puzzling this for a bit. I think this is wrong,

try code like:

outcome "rock" "scissors".
outcome "scissors" "paper".
outcome "paper" "rock".

player "player1".
player "player2".
move Move :- outcome Move _.

plays P N is? Move :- round N, player P, move Move.

round 1.
round (INT_PLUS Round 1) :-
  plays "player1" Round is Move,
  plays "player2" Round is Move.

if <builtin-identifier> was a mystyped <builtin> then INT_PLUS would be valid here, but it is not.

I believe that <builtin-identifier> is either just a normal <identifier> and the distinction should be removed, or else <builtin-indentifier> should be added to Tokens and "#builtin" <builtin> <identifier> [ "." ] should be "#builtin" <builtin> <builtin-identifier> [ "." ]

[mingodad]

It seems that #builtin is like typedefin C/C++ and so as I said before the grammar is context sensitive.
Edited: case sensitive -> context sensitive.

[robsimmons]

I think the best way to fix the grammar here is to just replace <builtin-identifier> with <identifier> — the initial syntax parse doesn't distinguish identifiers (a previous iteration probably did, and this is just an artifact).

[robsimmons]

@mingodad with #103 merged the syntax spec is (correctly) no longer context sensitive — the parser hasn't been relying on the context of previous builtin declarations for awhile

[robsimmons]

I appreciate you starting this discussion because it clarified the status of <builtin-identifier>. However, I'm not sure what the next actionable step is: @mingodad, do you have a thought about how this should be incorporated into the docs in some way? (An example of similar language documentation would be helpful here.) Otherwise it probably makes sense to close this issue.

[mingodad]

Here is an example https://ricomariani.github.io/CG-SQL-author/docs/ that have a link to https://ricomariani.github.io/CG-SQL-author/cql_grammar.railroad.html