dc30e44b60
New plan to [fix the `sbt` build](https://www.pivotaltracker.com/n/projects/2539304/stories/182209126) and its annoying: ``` log.error( "Truffle Instrumentation is not up to date, " + "which will lead to runtime errors\n" + "Fixes have been applied to ensure consistent Instrumentation state, " + "but compilation has to be triggered again.\n" + "Please re-run the previous command.\n" + "(If this for some reason fails, " + s"please do a clean build of the $projectName project)" ) ``` When it is hard to fix `sbt` incremental compilation, let's restructure our project sources so that each `@TruffleInstrument` and `@TruffleLanguage` registration is in individual compilation unit. Each such unit is either going to be compiled or not going to be compiled as a batch - that will eliminate the `sbt` incremental compilation issues without addressing them in `sbt` itself. fa2cf6a33ec4a5b2e3370e1b22c2b5f712286a75 is the first step - it introduces `IdExecutionService` and moves all the `IdExecutionInstrument` API up to that interface. The rest of the `runtime` project then depends only on `IdExecutionService`. Such refactoring allows us to move the `IdExecutionInstrument` out of `runtime` project into independent compilation unit. |
||
---|---|---|
.. | ||
src | ||
README.md |
Enso Runtime
The Enso runtime is responsible for the actual execution of Enso code. This means that it encompasses the following functionality:
- Parsing: Taking Enso code as input and generating an AST that maintains a sophisticated set of information about the input.
- Desugaring: Reducing the user-facing Enso code into a simplified language
known as
Core
. - Type Inference: Inferring the types of bindings in the user's code.
- Type Checking: Checking that the inferred and provided types for bindings match up across the codebase.
- Optimisation: Static optimisation processes to improve the performance of the user's program.
- Code Execution: Actually running the Enso code.
- Introspection Hooks: Providing hooks into the running code to allow the language server to inspect information about the code as it runs.
Truffle Nodes creation convention
All Truffle nodes that are expected to be created as part of ASTs should
implement a public, static build
method for creating an instance. If the node
is DSL generated, the build
method should delegate to the autogenerated
create
method, so that nodes are always created with build
. Such a
convention allows us to easily switch node back and forth between manual and DSL
generated implementations, without the need to change its clients.
The only exception are nodes that are never expected to be a part of an AST –
e.g. root nodes of builtin functions, for which an asFunction
method should be
implemented instead.
This convention should be implemented for every node throughout this codebase – if you see one not obeying it – please fix it.