Given that your average grandma will not be writing this SQL like text, but more likely technical users such as programmers, DBAs or others that will already be familiar with the concept of proper "programming language" syntax, I say throw the error back to the user, since they likely are already used to fixing minor syntactical errors.
A few examples that come to mind ...
- While editing a function within a google spreadsheet, it yells at you for any little thing being off.
- Task Queries in Atlassian's JIRA, are not forgiving as well and are broken until you correct them to exactly what is required.
- Then there's the countless number of programming languages, query languages and compilers that do the same thing, if something is off, the user needs to fix it or else they just give up.
Generally there is good reason to follow strict syntax requirements, namely you are telling a computer to perform specific functions or commands, and having any ambiguity may return undesired or varying results.
Considering the user experience involved with the user writing these queries, if the end results of "effectively the same" queries yield different results, then that user will have less trust in the query language to get exactly what they are querying for.
Sure it might be nice to help the user out by removing that extra comma, but what if later in your language you want to assign a special meaning to a double comma ",," or even an empty value between commas? Sure it might not happen, but by keeping the syntax strict you would later have the freedom to extend your language with additional features that may have been hampered by too loose of syntactical requirements early on.
Of course, if you don't foresee ever having a special meaning for ", ," then this arguably could be one place to make an exception; however, once you start making an exception in one place, it's easier to make them in other places as well, and pretty soon you could be maintaining a big mess of extra logic that could have been avoided.
I definitely would not correct the spelling of variables, such as subject. If you do then you may end up maintaining a big giant list of misspelled words that map to "subject", and if at some future time one of those misspelled variants actually was some other field name your system now supports, then this would break any existing saved queries, which would frustrate many users at that point.
To summarize, by keeping the syntax strict and simple, the experience of using a straightforward query language that does exactly what you tell it to do, would outweigh any minor inconvenience cause by small syntactical errors that I can quickly fix along the way.
