Register type definitions lazily

[4e6]

Pull Request Description

close #10923

Changelog:

• update: registerTypeDefinitions registers constructors lazily

Important Notes

The improvement of time spent in the registerTypeDefinitions method (highlighted):

before

after

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  TypeScript,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• Unit tests have been written where possible.

[JaroslavTulach]

• Few style-like comments inline. Treat as opinions.
• Overall this seems like the right change.
• what's the impact on benchmarks?
• explicitly: what's the impact on test/Benchmarks/src/Startup/*.enso startups?

[JaroslavTulach]

Does this new record have to be public? Because the record defines not just public constructor, but also public getters. I do not think we want people around the code base to call the getters.

enso/engine/runtime/src/main/java/org/enso/interpreter/runtime/callable/function/FunctionSchema.java

Line 235 in 0c41e8d

public static final class Builder {

Could we rather follow this example by @Akirathan where Pavel introduced FunctionSchema.Builder?

[JaroslavTulach]

The "tendency towards functional style" is clear...

[hubertp]

I, on the other hand, really like it :)

[JaroslavTulach]

Interesting use of the new map function. The alternative would be to have a single field Supplier<InitializationResult> stored in the AtomConstructor. I seem to like it a bit more - shows the "fixed" vs. the lazily computed part of the structure.

[JaroslavTulach]

With the builder style, this would become:

AtomConstructor.newBuilder().
  section(...).
  scope(...).
  assignments(...).
  reads(...).
  args(defs);

[Akirathan]

LGTM. Agree with @JaroslavTulach on the commenteds about style. You don't have to schedule the benchmarks and compare them on this PR, but remember to please at least add a comment on this PR about the results.