enso-org/enso
1
1
Fork 0
mirror of https://github.com/enso-org/enso.git synced 2024-11-24 08:41:40 +03:00
Code Issues Projects Releases Wiki Activity
941512e0ba
enso/engine/runtime
History
Hubert Plociniczak 941512e0ba
Optimize import/export resolution (#5700) 
This change adds serialization and deserialization of library bindings.
In order to be functional, one needs to first generate IR and
serialize bindings using `--compiled <path-to-library>` command. The bindings
will be stored under the library with `.bindings` suffix.
Bindings are being generated during `buildEngineDistribution` task, thus not
requiring any extra steps.

When resolving import/exports the compiler will first try to load
module's bindings from cache. If successful, it will not schedule its
imports/exports for immediate compilation, as we always did, but use the
bindings info to infer the dependent modules.

The current change does not make any optimizations when it comes to
compiling the modules, yet. It only delays the actual
compilation/loading IR from cache so that it can be done in bulk.
Further optimizations will come from this opportunity such as parallel
loading of caches or lazily inferring only the necessary modules.

Part of https://github.com/enso-org/enso/issues/5568 work.
2023-03-01 08:53:29 +00:00
..
src Optimize import/export resolution (#5700) 2023-03-01 08:53:29 +00:00
README.md Add a markdown style guide (#1022) 2020-07-21 13:59:40 +01:00

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.