d87a32d019
* Builtin Date_Time, Time_Of_Day, Zone Improved polyglot support for Date_Time (formerly Time), Time_Of_Day and Zone. This follows the pattern introduced for Enso Date. Minor caveat - in tests for Date, had to bend a lot for JS Date to pass. This is because JS Date is not really only a Date, but also a Time and Timezone, previously we just didn't consider the latter. Also, JS Date does not deal well with setting timezones so the trick I used is to first call foreign function returning a polyglot JS Date, which is converted to ZonedDateTime and only then set the correct timezone. That way none of the existing tests had to be changes or special cased. Additionally, JS deals with milliseconds rather than nanoseconds so there is loss in precision, as noted in Time_Spec. * Add tests for Java's LocalTime * changelog * Make date formatters in table happy * PR review, add more tests for zone * More tests and fixed a bug in column reader Column reader didn't take into account timezone but that was a mistake since then it wouldn't map to Enso's Date_Time. Added tests that check it now. * remove redundant conversion * Update distribution/lib/Standard/Base/0.0.0-dev/src/Data/Time.enso Co-authored-by: Radosław Waśko <radoslaw.wasko@enso.org> * First round of addressing PR review * don't leak java exceptions in Zone * Move Date_Time to top-level module * PR review Co-authored-by: Radosław Waśko <radoslaw.wasko@enso.org> Co-authored-by: Jaroslav Tulach <jaroslav.tulach@enso.org> |
||
|---|---|---|
| .. | ||
| 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.