7b0759f8b3
It appears that we were always adding builtin methods to the scope of the module and the builtin type that shared the same name. This resulted in some methods being accidentally available even though they shouldn't. This change treats differently builtins of types and modules and introduces auto-registration feature for builtins. By default all builtin methods are registered with a type, unless explicitly defined in the annotation property. Builtin methods that are auto-registered do not have to be explicitly defined and are registered with the underlying type. Registration correctly infers the right type, depending whether we deal with static or instance methods. Builtin methods that are not auto-registered have to be explicitly defined **always**. Modules' builtin methods are the prime example. # Important Notes Builtins now carry information whether they are static or not (inferred from the lack of `self` parameter). They also carry a `autoRegister` property to determine if a builtin method should be automatically registered with the type. |
||
|---|---|---|
| .. | ||
| 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.