SyntaxEditor ISyntaxLanguage Parse extension method

Hi Simon,

The Parse extension method first checks the language for an IParser service.  Then it makes a new CodeDocument behind the scenes and gets an ITextBufferReader for that document's snapshot.  Then it builds a ParseRequest and passes the snapshot to the IParser.Parse method.  The results are returned from the extension method.

You should put a breakpoint in your IParser implementation to see if it even gets called.  Then if not, use the info above to see if you can figure out what might be wrong.

Hi,

Thanks for the response. At this point, I'm going to admit I'm in a state of confusion. I have the sql language definition from the sample and that is what I'm loading as a stream into the SyntaxEditor Document's Language property.

I don't have any additional services at this time; no outlining, no tagging etc.

The document, as typed into the editor or loaded from a file does highlight keywords etc correctly. I assumed all this was driven by the language definition loaded as a stream into the Language property.

Does this mean that the Parse extension method won't work? If not, I'm a bit stumped. What more do I need to implement, or do I have to generate an IParseRequest?

Again, thanks for the help. Any more advice you can give is greatly appreciated. :)

Simon

Hi Simon,

The free sample SQL language definition just has a lexer only, meaning it only does syntax highlighting.  We don't define an IParser for it.  Thus unless you defined an IParser service on the language yourself, the Parse extension method will return null.

On the other hand, if you called the Parse extension method on one of our premium add-on languages (like the C# or VB ones in the .NET Languages Add-on), those do define IParser services and will return results from the Parse extension method.

Hi,

Yup, when I've dug deeper there is no parser registered on that language.

Is it possible to point me at a guide to creating a parser?

It sounds difficult, but it might not be?

Thanks for moving me on though. I've come up with another way of solving my immediate problem that doesn't need a parser, but I'm wondering if one might help me later on. For example, would it be the parser that is vital to providing completion?

Anyway, thanks for the immediate advice, any answer to the above questions greatly received.

Simon

Hi Simon,

A parser generally performs two main tasks: validating the syntax and creating an AST (abstract syntax tree) of the document.  If your parser logs syntax errors, SyntaxEditor can automatically put squiggle lines under them and if the user hovers over them, they get a quick info tip with the related error message.  The AST is useful because then you have a tree structure of what is in the code.  Many times, depending on the language, that sort of thing is very helpful in doing automated IntelliPrompt.

Our Getting Started series provides an excellent walkthrough of building a complete language, with parsing and automated IntelliPrompt.  Walking through it is a good place to start if you anticipate needing to build a parser.

However note that even when you use a helpful parser framework (like our LL(*) Parser Framework), building a parser grammar for a complex language can take days or even weeks of work to get right.  The C#/VB parser grammars we built for our .NET Languages Add-on took weeks of work each.

SQL is also a rather ambiguous language too, so it might be a tricky (time-consuming) one to make a grammar for.  I know we have customers who have done so though.

The other alternative is if you can find a third-party parser out there on the web, you could integrate it with SyntaxEditor by wrapping an IParser-based service around it.  That way you don't need to write the parser grammar yourself but can still get results from it.

Evening,

Thanks for the information. I know you are absolutely right; to create my own parser for such an open-ended language like SQL could become a massive hole for my time. Being honest, it's not really an avenue I have much time to devote going down.

I'm thinking I might be able to get away with grabbing a snapshot reader for an identified statement, then based on the caret position, I might be able to walk the token list to build a good enough picture to know about tables and fields at the current level. I say current level because in a sub-query, I should really know about the tables in the outer query.

I have had a search for a 3rd party parser I could wrap with the IParser interface (a great idea), but the best I could find is http://sqlparser.com/ However, I think this component, for $449 just doesn't cut the code completion requirement, since an incomplete SQL statement (actually fine as a picture for code completion) fails to parse at all.

Sorry to discuss 3rd party stuff in a post on your site; I wonder if you can recommend an alternative that would do this job?

Overall, code completion isn't critical, I have plenty of other more definite fish to fry, so this can go on the back burner.

Thanks for the guidance.

Simon

Hi Simon,

We haven't really looked at any third party SQL parsers in the past.  If anyone else has, please feel free to post them for Simon.

Parsers used for editors generally have to be designed to recover from errors with minimal impact to the resulting AST.  That's one thing we support well with our own parsing framework that we used to create our own advanced add-on language parsers.

Since SQL doesn't have too much of a hierarchy (other than sub-queries), as you said, you might be able to get away with just doing some token scanning for the statement you are on.

Hello,

Ok, thanks for all the information. This isn't a key thing for me yet as there is plenty of other stuff to be done. I shall look into third party support to help me on this when the time comes.

Thanks again.

Simon