One thing I like about the Functional Core, Imperative Shell architecture is that, if you gather input into an immutable record before sending it to your update function, then your handling of input becomes independent of the windowing/control library you use.

That would make it easier to switch to SDL or GLFW if you later want to since you only need to rewrite a minimal amount of code which converts the windowing library's inputs to your own record type. (Although it's not easy to abstract over drawing operations that way.)

If you'd like any help, I'm happy for you to shoot me an email (my email is in the repository's LICENSE file). Although there's still a lot I could learn more about too.

Comments URL: https://news.ycombinator.com/item?id=40734827

Points: 3

# Comments: 3

I thought it was the latter (that running a JIT on iOS would be possible but not accepted on the app store), but then I'm left wondering why they seem to have submitted a JIT-less version on a third party app store.

Maybe the intent was ease development by having only one version to support for the first-party and also third-party app stores.

Elm is an extreme case where indexing into an array returns a result type instead of an exception when the index is out of bounds, unlike most languages including Haskell.

Maybe my program logic is intended to always access only valid indices in an array, but here I'm given a result type where I have nothing to do in the error case since my code is never intended to reach that case. I would rather let the language throw an out-of-bounds exception here to tell me that my implementation is incorrect while I'm testing.

Same with libraries in a language. It really depends on the use cases of the library you're writing whether results or exceptions are better. The most convenient thing for the user of a library would be to provide both exception-throwing and result-passing alternatives. This is what the OCaml standard library does as well.

The UI for an LLM answer would have difficulty replicating the same thing since every answer is (probably) a new one and you have no input from other people about this answer too.

Edit: After writing my reply, I saw that roughly four other people (so far) made the exact same point and posted it a couple of minutes before. I think your question is a good one (made me think a little) and apologies it feels like you're being piled on.

Standard ML has some nice features though and I think what I mentioned is the only serious shortcoming (except for ecosystem if that's important to you).

Standard ML is also structurally (but strongly) typed, unlike F# and the vast majority of nominally typed languages, which is rare but nice.

type person = { age : int, name : string }

is the same as the type

type animal = { age : int, name = string }

but this hasn't been an issue foe me, and structural typing means you can avoid defining the type at all which is convenient for small records.

For example, a function to increment age has no need for you to define the type.

fun grow { name, age } = { name = name, age = age + 1 }

I think Standard ML helps you understand the origin of some common FP idioms. Like tuples are really just records and SML treats them as such. The empty record {} is the same as the empty tuple (): both are the unit type. And a record like { 1 : "a", 2 : "b" } is exactly the same as the tuple ("a", "b").

There is also MLKit's SMLtoJs which compiles to Javascript, but not to Lua.

https://github.com/melsman/mlkit/blob/master/README_SMLTOJS....

An ordered B-Tree iteration would jump between different arrays in the tree often, but a B+ Tree would only have you jump to another array once you’re done iterating over all the elements in the current array.

The following article says the same. https://www.scylladb.com/2021/11/23/the-taming-of-the-b-tree....

I was trying to point to the opinion of the majority that I've seen and what I have seen from most of the community when security is mentioned is that Apple needs stronger security from a technical standpoint rather than controlling what and what is allowed on users' devices. I think both opinions hold validity, and you may be right that there is more nuance.

This linked comment (which I randomly found on HN's search) summarises what I've seen here:

"The way these discussions usually go is that a bunch of Apple users complain about the restrictions, a bunch of Apple users say they like them, and a few Android users like myself remind the complainers that there are, in fact, other options that don't involve forcing Apple to take away the rules that most iOS users appreciate having."

https://news.ycombinator.com/item?id=39574040

I do recall a few users opposing allowing alternative app stores (which is the debate that is freshest in my mind) because they prefer to stick to Apple's, and the common rejoinder from the community that nothing is being taken away from those who prefer to stick to Apple's store but that other users who want something different have more choice.

I'm still curious about what additional nuance you have in mind, since I honestly can't remember seeing it.

VS Code is known to use a Piece Tree (Piece Table represented as a balanced binary tree) and I thought AbiWord (which this article also mentions) was the first to use the data structure. This article points out that the Tweak editor and the MText interface in the Modula-3 programming language uses the same approach, meaning this variant of the data structure goes back even further than I knew.

Rocq is similar to the Roc programming language which is confusing naming (and they sound identical as far as I know).

The talk is about segmenting IO and mutation from the rest of your program. The core of your program should be just pure functions and the IO part of your program should be "at the edge".

For example, consider a game loop. Game loops tend to have a while loop like this:

function loop() { while (should_not_close_window) { update(); // Run update function which updates mutable state draw(); // Draw from the mutable state } }

If we wanted to segment IO, we would return an immutable type/value from the update function instead like:

function loop(old_state) { const new_state = update(old_state); // Call a function which returns a new state given an old_state. draw(new_state); // Draw function still uses IO because drawing is inherently imperative

  if (new_state.should_not_close_window) {
    loop(new_state); // Call the loop function with the new state; this tail recursion replaces the previous while-loop). The program automatically exits the loop if new_state.should_not_close_window is false.
  }

The key thing is to turn as much of your program into a function that takes a value and returns a new value as possible, and let the IO code be only there for operations which cannot be done without IO (like drawing).

There are some cases where you might find yourself wanting to perform IO inside the update call but that can be handled by setting some state (inside your root state object) which the boundary of your program interprets as "do IO at the boundary".

For example, let's add an async handler to the loop (async often being IO like disk writes).

// Function to handle async messages function handleAsync(old_state) { for (const msg of old_state.msgs) { execMsg(msg); // Call function to pattern match and execute this specific message } const new_state = remove_msgs(old_state); // Call function that returns same state, except msgs is now the empty list (because the msgs have been handled) return new_state }

Where type msgs could be a list of types like | WriteFile of string | MaximiseScreen

The main loop will be modified by putting a call to this handleAsync function after update, like this:

function loop(old_state) { const mid_state = update(old_state); const new_state = handle_async(mid_state); draw(new_state);

  if (new_state.should_not_close_window) {
    loop(new_state);
  }

The majority of your code should be in the pure update() function which returns a new value (this example doesn't explain anything about pure functions at all) and IO should be minimised.

Generally, don't do IO (except at the boundary/root of your application). When you want to do IO, add some kind of message/datatype value to your state object and do the IO when your state object bubbles up, rreturning to the root of your application.

The talk likely explains this better but I hope my attempt at giving an explanation was helpful.

[1] https://www.destroyallsoftware.com/talks/boundaries

There is the still the ongoing debate about how much human perception and human reason are shaped by cultural forces vs. universal forces (where the latter asserts humans reason in the same/similar ways).

There's evidence that certain optical illusions don't work across cultures for example (I seem to remember those in Western countries have a tendency to mentally group things in rectangular boxes). The exact balance between cultural and universal forces isn't known and I doubt we could say anything about sum types in that regard.