This is far from polished and complete but here you can see the grammar defined in foo.g being dynamically compiled and used to parse the text in the grammar console. You can see how the [Keyword] attribute is used to generate syntax highlighting in that grammar window also, as well as automatic error generation for the errant ‘!’.
Next up is visualization of the node graph produced by the parse as well as error information. Very promising progress though!
It would probably have helped to have someone sit down and show me but I had a real hard time understanding exactly what the various solutions were. But other than not fully getting the specifics I think I got the general idea and was able to add two new error handling semantics to meta#.
Parsing errors basically all boil down to a single type of problem: the thing that is next in the stream is not what you were expecting. I decided that you could look at this problem two different ways. You could either say that something you expect is missing or something you didn’t expect is present.
So I added two new pattern semantics “error unless X” and “error until X”, where X is any pattern.
In the case of “error unless”, that is like saying something you expected is missing. In this case an error will be logged, input from the stream will not be consumed and null will be returned rather than fail. This will let whatever rule that uses these semantics to still project and give you a very specific message and if the following code is well formed the parser could even recover without any additional errors. This is very useful for missing ‘;’ at the end of statements.
For “error until”, it is like saying something you were not expecting is present. In this case all of the input will be consumed until the X pattern is matched. An error will be reported and fail will be returned. This is very good for sync’ing to the next close bracket because it will read all unknown input and treat it as an error.
One last way to report errors is just by calling context.LogError(…) from within a projection. Then you can handle more complex cases and log arbitrary error messages. I might have to expand the api for this but here is an example of how I’m using it so far.
If you’ve heard me talk about DSLs but just haven’t quite been sold on the idea yet, watch this video. In fact, watch it anyway. Dr. Alan Kay gives a very inspirational and interesting speech about the past, present and future of Computer Science, technological innovation and creativity. The grand finale ties all of his ideas together in a beautiful example of the power of domain specific languages.
I found myself nodding throughout this entire presentation and even though I didn’t know where it was going I could see how it applied to my own personal research in meta#. Thank you Dr. Kay, I may never need to spend my time explaining the why’s of DSLs again, I will simply forward them to this presentation.
Last time I tried this I had to use the old Managed Package Framework (MPF) APIs in vs2008 and it was so incredibly painful that I gave up and I have been scared to try again ever since. Well I tried again for vs2010 finally and managed to get it working in a single night! The new MEF based APIs are a real breeze comparatively speaking.
After an initial stumbling around period digging through tons of seemingly useless documentation I finally found an example of a language extension called Ook! And it was exactly what I needed. It also turns out that the API for doing highlighting in VS is setup exactly perfectly for the way I am providing highlighting metadata in MetaSharp. What a happy coincidence! This isn’t committed yet but it’s a very encouraging start.