enso/engine/runtime
Jaroslav Tulach 4465d63dd8
Improved polyglot Date support (#3559)
Significantly improves the polyglot Date support (as introduced by #3374). It enhances the `Date_Spec` to run it in four flavors:
- with Enso Date (as of now)
- with JavaScript Date
- with JavaScript Date wrapped in (JavaScript) array
- with Java LocalDate allocated directly

The code is then improved by necessary modifications to make the `Date_Spec` pass.

# Important Notes
James has requested in [#181755990](https://www.pivotaltracker.com/n/projects/2539304/stories/181755990) - e.g. _Review and improve InMemory Table support for Dates, Times, DateTimes, BigIntegers_ the following program to work:
```
foreign js dateArr = """
return [1, new Date(), 7]

main =
IO.println <| (dateArr.at 1).week_of_year
```
the program works with here in provided changes and prints `27` as of today.

@jdunkerley has provided tests for proper behavior of date in `Table` and `Column`. Those tests are working as of [f16d07e](f16d07e640). One just needs to accept `List<Value>` and then query `Value` for `isDate()` when needed.

Last round of changes is related to **exception handling**. 8b686b12bd makes sure `makePolyglotError` accepts only polyglot values. Then it wraps plain Java exceptions into `WrapPlainException` with `has_type` method - 60da5e70ed - the remaining changes in the PR are only trying to get all tests working in the new setup.

The support for `Time` isn't part of this PR yet.
2022-07-21 06:32:40 +00:00
..
src Improved polyglot Date support (#3559) 2022-07-21 06:32:40 +00:00
README.md Add a markdown style guide (#1022) 2020-07-21 13:59:40 +01:00

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.