Abstracting AST essentials into Irony.Parsing.AST

Oct 12, 2012 at 9:53 PM

Roman,

I have made a first pass at abstracting the bare esentials of Irony.Interpreter.Ast.AstNode into an abstract class that uses only definitions of Irony.Ast and Irony.Parsing, plus two new objects:

public interface IScriptThread{
   Irony.Ast.AstNode CurrentNode { get; set; }
   void ThrowScriptError(string error, BnfTerm sender);
}
public interface IScopeInfo{ }


This has allowed me to completely remove all references to Irony.Interpreter
from my music parser, with no ill effects. Do you possibly have time to
review this for general inclusion?
Pieter
Oct 13, 2012 at 4:58 AM

I think incorporating this would be an (albeit small) step forward on your code clean-up project. The new base clase, Irony.Ast.AbstractAstNode incorporates about 70 or 75% of the original, and implements just the two interfaces IAstNodeInit and IBrowsableAstNode. This now provides a suitable base for the AST structure of my music parser, both stand-alone and within GrammarExplorer, without any references to namespace Irony.Interpreter.

Pieter

 

Oct 15, 2012 at 7:13 PM

Hi Roman,

Hmmm! More complex than I initially realized. Althought my proposal above nicely supports the music parser's needs, it does not come close to supporting the Irony.Interpreter implementation.

I have made a couple of passes at attempting to adapt this into Irony.Interpreter, but they all quickly collapse under their own weight. Part of the problem is that I do not recognize the desingnpattern you are using with the implementation of Evaluate and DoSetValue in AstNode.cs. Can you possibly point me at a reference for this? Thanks very much.

Pieter

Coordinator
Oct 15, 2012 at 7:20 PM

Hi

sorry for being silent for so long, had been busy and away. Will get to this tonight, and will look at other threads. 

Roman

PS - really appreciate your help to other folks on some simple issues - thank you!

Oct 15, 2012 at 8:06 PM

My pleasure.  I look forward to your comments.

Pieter

Coordinator
Oct 16, 2012 at 5:39 PM

I don't quite see what the problem here. Irony assembly declares two generic interfaces for AST nodes to be 'viewable' in Grammar explorer. And Irony.Interperter provides an implementation of AstNode for interpreter/scripting language implementation. You were able to invent your own AST tree/classes for your specific purpose - which assures that the idea works well. And the idea is - very small, compact basic interface for communicating with grammar Explorer and using default AST instantiation, plus an example/reference/starting point implementation for interpreter. Either use provided AST node or build your own - which you did. Why invent more?! 

Oct 16, 2012 at 6:01 PM
Edited Oct 16, 2012 at 6:02 PM

My thinking was that an implementation of a basic AST-tree-walker would be very useful in Irony; and I am the type who always strives for perfection.

The inspiration came from encountering near constant run-time exceptions from the moment LanguageFlags.CreateAst was set until the AST tree was perfect. Not an issue for me any longer, as I have built such an Ast-tree-walker in a private extension of Irony.Ast, but surely others have encountered this also once they wander away from Programming language grammars.

However, perhaps it is my understanding of the design that is imperfect, rather than the code, as I am still low on the learning curve for Irony.Interpreter. Let me think on it again.