Hello Jochen
Thank you for your detailed email. Rethinking my ask, and summarizing at the
same time.
Your short answer is no you cannot customize the parrot parser to do this.
But I can build using the internal method chaining
But, one of my limitations is that I am not executing/defining this SQL, its
parsed and executed through a library which means I dont want to deal with
building the syntax in Groovy, nor do I want to break up its execution based on
the syntax
But it would be nice to debug, which means, like you said, I need to find out
parts that can be executed atomically and move them out to be stored as
separate variables.
Or I let the library do its thing(to make sure I dont make assumptions about
how its going to execute) and return to me all intermediate results it
gathered, which can be viewed in the debugger if held in a temporary variable.
This makes sense. Thank you for this enlightenment
regards
Saravanan
On 2020/08/09 11:09:37, Jochen Theodorou <blackd...@gmx.org> wrote:
> 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
>
