On 09.08.20 01:54, Saravanan Palanichamy wrote:
Hello everyone
If I wanted to introduce new syntax in my groovy script, how would I go about
doing it? I want to embed custom syntax directly into the groovy file and have
it be parsed into my custom AST nodes. An example would be
myFunction() {
List<MyTableValues> tableValues = select value from mySQLTable where
(select tableName from myTableNames where user = $userName)
... Use table Values
}
if you have
List<MyTableValues> tableValues = select value from mySQLTable where (select
tableName from myTableNames where user == userName)
the Groovy parser should parse this as:
List<MyTableValues> tableValues =
select(value).from(mySQLTable).where(select(tableName).from(myTableNames).where(user
== userName))
which means except that I have userName instead of $userName it should
be valid syntax.
I want to enable a few behaviors
a) Check for syntax correctness (which is why I want to parse using antlr
grammar)
b) Check for semantic correctness (I suppose if I parsed this into my custom
AST nodes, that takes care of that. I could make an SQLExpressionASTNode and
validate things there)
c) Enable a debug experience where I am able to see the result of the inner SQL
first and then see it move to the outer SQL (this would be super awesome, but I
realize this is in the purview of the groovy IDE plugin. I am asking here to
see if I can get any pointers)
Groovy is a good language for inner DSLs, that is DSLs written in the
syntax of the language. Partially because of that Groovy is quite a
complex language, and complex languages tend to be a tad difficult to
extend further on the grammar level. Which is why we do not really
provide hooks into our antlr code for people to extend this. Long ago we
had the idea of specially marked blocks for which you can define your
own sub grammar, but it never seemed really to come to a acceptable
solution.
Another idea is of course to just use a string, as you wrote:
My limited ideas so far are to annotate the List declaration with @SQL, hook
into the semantic phase to translate the select clause (embedded in a gstring)
into a validated, redirect into a custom function call.
so if I see
@SQL List<MyTableValues> tableValues = "select ...."
I'll convert it to
@SQL List<MyTableValues> tableValues = sqlRunner.run("select ...")
This does not get me debuggability though and it feels contrived
To get debuggability you will need to place the inner/outer SQL into
variables with line number information (and noncolliding names maybe) in
your new AST.
I prefer the String solution these days
bye Jochen
