4fc6dcced0
This is a step towards the new language spec. The `type` keyword now means something. So we now have ``` type Maybe a Some (from_some : a) None ``` as a thing one may write. Also `Some` and `None` are not standalone types now – only `Maybe` is. This halfway to static methods – we still allow for things like `Number + Number` for backwards compatibility. It will disappear in the next PR. The concept of a type is now used for method dispatch – with great impact on interpreter code density. Some APIs in the STDLIB may require re-thinking. I take this is going to be up to the libraries team – some choices are not as good with a semantically different language. I've strived to update stdlib with minimal changes – to make sure it still works as it did. It is worth mentioning the conflicting constructor name convention I've used: if `Foo` only has one constructor, previously named `Foo`, we now have: ``` type Foo Foo_Data f1 f2 f3 ``` This is now necessary, because we still don't have proper statics. When they arrive, this can be changed (quite easily, with SED) to use them, and figure out the actual convention then. I have also reworked large parts of the builtins system, because it did not work at all with the new concepts. It also exposes the type variants in SuggestionBuilder, that was the original tiny PR this was based on. PS I'm so sorry for the size of this. No idea how this could have been smaller. It's a breaking language change after all. |
||
|---|---|---|
| .. | ||
| 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.