A bit of an abstract topic

[seadiem]

Hi, I can't find an answer to the question about how the program is structured in pure value semantics. ChatGPT told me that these are the very schemes of the Hylo program

func loop(model: GameModel) {
    let input = waitForInput()
    let newModel = update(model, input)
    render(newModel)
    loop(model: newModel)
}

That is, it is a recursive function that calls itself with a new value. At the same time, there is some asynchronous input (from hardware, network or framework). He also says that you can save our state outside this loop, like a global variable, but this is very bad. Is he right?

[kyouko-taiga]

You made the right choice asking humans!

Hylo advocates for mutable value semantics, which means we retain the ability to modify (part of) values in place. So you can write your program as follows:

fun main() {
  var model = GameModel()
  while true {
    let inout = wait_for_input()
    &model.update(input)
    model.render()
  }
}

There's nothing wrong with tail recursion. In fact the code that you wrote should normally compile to a while loop (assuming a decent optimizer). It's more "functional" than the in-place update I have shown but it is equivalent. That's actually part of the beauty of mutable value semantics.

Several of the people working on Hylo have talked about MVS in more depth in various places so I won't write a novel here. You can check the README page of the compiler's repo for a few links to relevant talks and papers. Of course you're also welcome to come back here if you have any specific question.

[tothambrus11]

Hi,
That will depend on the rendering framework people implement in Hylo. There are many alternatives:

• immediate mode UI, like egui
• a more declarative approach, like SwiftUI
• a functional-style architecture, like Elm

Actually, you could take a look at both Swift and Rust, and I would think most if not all ideas about UI handling could be transferred to Hylo. The language guarantees are not the same, but very similar on the surface - eliminating shared mutation of state, though with some different tools. I would encourage you to watch Dave's keynote from last year's C++ On Sea conference for seeing the differences from C++, Rust and Swift.

Regarding the handling of inputs, we are going to leverage structured concurrency in order to safely work with asynchronous things. Learning about senders/receivers in C++ helped me understand structured concurrency better (though in C++ they are very complicated, Hylo really streamlines their usage in a much simpler way). At the lowest level, there will be some unsafe things interfacing with the operating system, but on the surface it's enough for you to write function calls and not worry about that they are a "blocking" call (waiting for keyboard inputs), thanks to thread-hopping.
For handling external inputs, I see at least two viable options:

• in the render loop of the UI, check if the keyboard event queue has any elements, and handle each one by one.
• create some kind of a lazy Iterable wrapper around keyboard events, so that you can iterate over them whenever they arrive (dereferencing an iterator would then block until the element becomes available).

for event in os.keyboard_events() { 
   if event.key == Keys.ENTER {
     print("hello")
   }
}

[dabrahams]

@seadiem I think you're laboring under a misconception. At a high level, there's zero difference in execution order between Hylo and any other procedural language. The “long-lived islands in memory” you are thinking of in a UI program are only long-lived because they are owned by at least one other thing. In every UI framework I've seen, that's ultimately a loop. The loop may be hidden in the framework, so you have the illusion that you're just “putting the object out there,” but it's there.

for someone who is coming from a object-oriented reference-based language the most comfortable accurate mental model (though definitely not the simplest model) is to think of Hylo as only permitting one reference to any given thing, and otherwise being just like any other language you've used. There's no reason that the broad strokes of using a UI framework in Hylo need to look different from one in any other procedural language. The differences arise because the object graph always looks like a tree in Hylo, so you find different ways to express the non-ownership relationships in your UI system.

[dabrahams]

@seadiem did that make sense to you?

[seadiem]

Yes, this is generally a comprehensive answer for me at the moment. Particularly interesting about the relationships of objects in the form of a tree. I am currently digesting and looking for information about this. I watched Sean's lectures on YouTube but understood almost nothing.

[dabrahams]

I think my 2022-09 talk might serve you better in this particular case (see also other relevant talks). Sean's talks predate the formalization of Mutable Value Semantics.