Generate an interpreter entry-point on ATerms #43
Labels
Milestone
Comments
|
Also evaluate a text file containing a String representation of an ATerm. |
|
Handy for @milosonator (Grace). |
|
I can see the following usage scenarios for full-program evaluation:
All of the above should be runnable in both an existent and in a new context. It then becomes interesting to be able to evaluate parts of programs in a new or in an existent context, reading the program into the interpreter in the 3 ways described above. |
Balletie
added a commit
to spoofax-shell-2016/dynsem
that referenced
this issue
May 30, 2016
This commit defines a new abstract class, DynSemEntryPoint, which is responsible for instantiating the VM with the proper dependencies: a parser, specification term, and a term registry. The dependencies are injected by passing them as "configuration" to the VM builder (see PolyglotEngine.Builder#config). The configuration parameters are then retrieved when creating the DynSemContext in DynSemLanguage#createContext. This allows to inject ones own "parsers", for example a parser which does not parse, but just returns an ATerm. Thus an entry point can be created which evaluates ATerms instead of just program source code (see issue metaborg#43).
Balletie
added a commit
to spoofax-shell-2016/dynsem
that referenced
this issue
May 30, 2016
This commit defines a new abstract class, DynSemEntryPoint, which is responsible for instantiating the VM with the proper dependencies: a parser, specification term, and a term registry. The dependencies are injected by passing them as "configuration" to the VM builder (see PolyglotEngine.Builder#config). The configuration parameters are then retrieved when creating the DynSemContext in DynSemLanguage#createContext. This allows to inject ones own "parsers", for example a parser which does not parse, but just returns an ATerm. Thus an entry point can be created which evaluates ATerms instead of just program source code (see issue metaborg#43).
Balletie
added a commit
to spoofax-shell-2016/dynsem
that referenced
this issue
Jun 1, 2016
Long commit message incoming, see TL;DR at the bottom for short message. Since this is a meta-interpreter, it makes sense to pass the specification term to the eval method, instead of program source for that interpreter. We pass the DynSem specification, and use it to fill the rule registry. The RuleRoots in the rule registry are then available for foreign access, as is the case with DynSemPrimedRun before this commit. However, this commit renders DynSemPrimedRun unnecessary, so it has been removed and replaced with DynSemRule (a wrapper around RuleRoot). Now a client/library user of the interpreter can invoke any rule by finding the rule with PolyglotEngine#findGlobalSymbol with a rulekey (e.g. "init/Program/1"), and then calling the rule with a program term (ITerm) and (optionally) semantic components. Since we now parse the specification term instead of program source code, the parser is no longer needed in the DynSemContext and does not have to be used by a generated subclass of DynSemLanguage. Parsing is now completely separate from interpretation and the PolyglotEngine#eval method, thus improving reusability. **TL;DR:** In short, the benefits that this commits brings are: 1) The parsing can be done outside of the parse method in the generated language class. 2) Because of 1), providing an entry point for ASTs is trivial, since the interpreter can now be called directly with ITerms. (issue metaborg#43) 3) Any rule can now be invoked by a client that has the generated interpreter in the classpath. Previously this was not possible. 4) It makes the whole thing more logical, as it is consistent with the rest of the idea of a "meta-interpreter": you pass the interpreter specification which results in an interpreter as output.
Balletie
added a commit
to spoofax-shell-2016/dynsem
that referenced
this issue
Jun 1, 2016
Long commit message incoming, see TL;DR at the bottom for short message. Since this is a meta-interpreter, it makes sense to pass the specification term to the eval method, instead of program source for that interpreter. We pass the DynSem specification, and use it to fill the rule registry. The RuleRoots in the rule registry are then available for foreign access, as is the case with DynSemPrimedRun before this commit. However, this commit renders DynSemPrimedRun unnecessary, so it has been removed and replaced with DynSemRule (a wrapper around RuleRoot). Now a client/library user of the interpreter can invoke any rule by finding the rule with PolyglotEngine#findGlobalSymbol with a rulekey (e.g. "init/Program/1"), and then calling the rule with a program term (ITerm) and (optionally) semantic components. Since we now parse the specification term instead of program source code, the parser is no longer needed in the DynSemContext and does not have to be used by a generated subclass of DynSemLanguage. Parsing is now completely separate from interpretation and the PolyglotEngine#eval method, thus improving reusability. **TL;DR:** In short, the benefits that this commits brings are: 1) The parsing can be done outside of the parse method in the generated language class. 2) Because of 1), providing an entry point for ASTs is trivial, since the interpreter can now be called directly with ITerms. (issue metaborg#43) 3) Any rule can now be invoked by a client that has the generated interpreter in the classpath. Previously this was not possible. 4) It makes the whole thing more logical, as it is consistent with the rest of the idea of a "meta-interpreter": you pass the interpreter specification which results in an interpreter as output.
gfokkema
pushed a commit
to spoofax-shell-2016/dynsem
that referenced
this issue
Jun 7, 2016
This commit defines a new abstract class, DynSemEntryPoint, which is responsible for instantiating the VM with the proper dependencies: a parser, specification term, and a term registry. The dependencies are injected by passing them as "configuration" to the VM builder (see PolyglotEngine.Builder#config). The configuration parameters are then retrieved when creating the DynSemContext in DynSemLanguage#createContext. This allows to inject ones own "parsers", for example a parser which does not parse, but just returns an ATerm. Thus an entry point can be created which evaluates ATerms instead of just program source code (see issue metaborg#43).
gfokkema
pushed a commit
to spoofax-shell-2016/dynsem
that referenced
this issue
Jun 7, 2016
Long commit message incoming, see TL;DR at the bottom for short message. Since this is a meta-interpreter, it makes sense to pass the specification term to the eval method, instead of program source for that interpreter. We pass the DynSem specification, and use it to fill the rule registry. The RuleRoots in the rule registry are then available for foreign access, as is the case with DynSemPrimedRun before this commit. However, this commit renders DynSemPrimedRun unnecessary, so it has been removed and replaced with DynSemRule (a wrapper around RuleRoot). Now a client/library user of the interpreter can invoke any rule by finding the rule with PolyglotEngine#findGlobalSymbol with a rulekey (e.g. "init/Program/1"), and then calling the rule with a program term (ITerm) and (optionally) semantic components. Since we now parse the specification term instead of program source code, the parser is no longer needed in the DynSemContext and does not have to be used by a generated subclass of DynSemLanguage. Parsing is now completely separate from interpretation and the PolyglotEngine#eval method, thus improving reusability. **TL;DR:** In short, the benefits that this commits brings are: 1) The parsing can be done outside of the parse method in the generated language class. 2) Because of 1), providing an entry point for ASTs is trivial, since the interpreter can now be called directly with ITerms. (issue metaborg#43) 3) Any rule can now be invoked by a client that has the generated interpreter in the classpath. Previously this was not possible. 4) It makes the whole thing more logical, as it is consistent with the rest of the idea of a "meta-interpreter": you pass the interpreter specification which results in an interpreter as output.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sometimes it's desirable to evaluate and AST rather than a program which needs to first be parsed. The generated language interpreter entry point should have a method that takes an AST instead of a
Source.The text was updated successfully, but these errors were encountered: