Easy way to delay & cache computed atom fields

[JaroslavTulach]

#6073 as well as #5085 are in need of efficient, properly implemented lazy atom fields. The engine is in the best position to deliver it. The alternative is to create a Lazy type in the libraries, but that's a hacky and ugly solution. There should be no Lazy type in the libraries, but the support shall come from the engine:

• Provide metadata for widgets lazily #5085
• we have a prototype that shows how it all can be done
• the API will be simpler - just ~ in front of the atom field
• the access to the field will be transparent - no difference between lazy/cached/eager field
• the performance will be better if this is implemented in the engine
• we'll use less memory, if this is done in the engine as we eliminate delegation once the field is materialized/cached

Library guys would be delighted - #6073 (comment) - to get " a more efficient engine solution - I will be really happy to have it replaced. The benefits sound cool."

Initial investigation tried to evaluate following program:

from Standard.Base import IO

type Lazy
    Value ~x ~y

    say self w = "Hello " + w.to_text

    meaning self = 
        IO.println "Computing meaning"
        v = self.x * self.y
        IO.println "Computed meaning"

main =
    compute_x =
        IO.println "Computing x"
        v = 6
        IO.println "Computing x done"
        v

    compute_y =
        IO.println "Computing y"
        v = 7
        IO.println "Computing y done"
        v

    IO.println "Start"
    l = Lazy.Value compute_x compute_y
    IO.println "Lazy value ready"
    IO.println <| l.say "Světe!"
    IO.println l.meaning
    IO.println <| l.say "Again!"
    IO.println l.meaning

to my biggest surprise it:

• already compiles - e.g. ~ is acceptable value for constructor arguments
• it delays the computation of ~x and ~y fields already
• however it computes the fields again and again whenever they are accessed

E.g. what we need to do is to make sure each such ~ field is computed just once.

Tasks:

• Use the prototype to store lazy values in Atom but obtain them like normal values
• Modify the IR phases to allow ~ in Atom constructors
• Verify no non-lazy Atom benchmarks are affected by this change
• Create benchmark for Atoms with "lazy values" - it shall show there is some overhead of using laziness compared to strict Atom values

[enso-bot]

Jaroslav Tulach reports a new STANDUP for yesterday (2023-04-05):

Progress: - lazy atom fields integrated: #6151

• Text.to_display_text integrated: Text.to_display_text is (shortened) identity #6174
• Review withContextEnabled: https://github.com/enso-org/enso/pull/6171/files#r1158050319
• Investigation of InliningRecursionDepth: If cascades 5x slower than case-of due to limit of recursive inlining #5709 (comment)
• meetings It should be finished by 2023-04-06.

Next Day: Consolidate Array & Vector

GitHub

Replace IOContexts with execution env and contexts by hubertp · Pull Request #6171 · enso-org/enso

Pull Request Description As per design, IOContexts controlled via type signatures are going away. They are replaced by explicit Context.if_enabled runtime checks that will be added to particular me...