Workflow: Calling stochastic functions for instances

[OAGr]

One pattern that's emerged in the recent Virus model, is one in which we kept adding specific parameters to a "Room". As a simple example, imagine that I'm generating a person:

makePerson() = {
  age: pick(5 to 10)
}

In some cases, I might want to generate a gender, like:

getGender(person) = pick(mx(0, 1)) > 0.5 ? "Male" : "Female"

Later, I might want to estimate lifespan. This would ideally use the age and gender functions. But it would be annoying to track these. Right now, I could do something like,

person = makePerson() -> {|p| Dict.set("gender", getGender(p))} -> {|p| Dict.set("expectedLifespan", getExpectedLifespan(p))} 

This gets really messy, because we now have a person object that changes in params based on it's previous calls, and we need to keep track of what's been called before calling other things. Here, we'd need to call getGender before we call expectedLifepan.

In JS, we could solve this with something like a class with some caching/memoization.

class Person {
  constructor() {
    this._age = Math.floor(Math.random() * 101); // Random age between 0 and 100
    this._gender = null; // Initialize with null to indicate it's not set yet
    this._expectedLifespan = null;
  }

  get gender() {
    if (!this._gender) {
      this._gender = Math.random() > 0.5 ? "Male" : "Female";
    }
    return this._gender;
  }

  get lifespan() {
    if (!this._expectedLifespan) {
      const age = this._age;
      const gender = this.gender; // Call the gender getter, which will initialize _gender if it's not set
      // Hypothetical formula for lifespan based on age and gender
      let lifespan
      if (gender === "Male") {
        lifespan =  60 - age + random(10,20); // Let's assume males have an expected lifespan of 80 years
      } else {
        lifespan = 65 - age + random(10,20); // And females have an expected lifespan of 85 years
      }
    }
    this._expectedLifespan = lifespan
    return this._expectedLifespan
  }
}

GPT4 recommend this in OCaml. Having some Some type would be useful for this.

type person = {
  age: int;
  mutable gender: string option;
  mutable lifespan: int option;
}

let create_person age = {
  age = age;
  gender = None;
  lifespan = None;
}

let random_gender () = if Random.float 1.0 > 0.5 then "Male" else "Female"
let random_age () = Random.int 101

let get_gender p =
  match p.gender with
  | Some g -> g
  | None ->
    let g = random_gender () in
    p.gender <- Some g;
    g

let calculate_lifespan age gender =
  let base = if gender = "Male" then 80 else 85 in
  base - age

let get_lifespan p =
  match p.lifespan with
  | Some l -> l
  | None ->
    let l = calculate_lifespan p.age (get_gender p) in
    p.lifespan <- Some l;
    l

let person_with_new_age p new_age =
  { p with age = new_age; lifespan = None }
(* Notice that gender is retained, but lifespan is reset to None so it can be recalculated *)

(* Usage *)
let () =
  let p = create_person (random_age ()) in
  Printf.printf "Gender: %s\n" (get_gender p);
  Printf.printf "Lifespan: %d\n" (get_lifespan p);
  let older_person = person_with_new_age p (p.age + 1) in
  Printf.printf "Older Lifespan: %d\n" (get_lifespan older_person)

GPT4 recommends to either use the mutability or laziness features of OCAML. Without those, it seems tough.

I'm not really sure how to best this with an immutable language with Squiggle at this point. I imagine that Structs could help a lot here, especially if there are many params, and each/most can be None/undefined.

Memoization (#1606) could likely do the job, though might be tricky to get right.

[berekuk]

I'm not really sure how to best this with an immutable language with Squiggle at this point. I imagine that Structs could help a lot here, especially if there are many params, and each/most can be None/undefined.

This might make things messy, because nulls are a frequent source of errors.

Example

We have a similar pattern in SquiggleProject/ProjectItem, where fields source, ast, imports, output are populated in this order, and the entire ProjectItem is a class.

It leads to this awkward code:

  async run(context: ReducerContext, externals: ImmutableMap<string, Value>) {
    if (this.output) {
      return;
    }

    this.buildAst();
    if (!this.ast) {
      // buildAst() guarantees that the ast is set
      throw new Error("Internal logic error");
    }

(this is repeated for each step)

This is because the information that the field is now set is not reflected in how the code organized, and not specified in types.

So when you set a field, you have to remember that yourself and analyze the code flow in your head to make sure that there are no bugs. When you put the code for generating each field in methods, you don't have any guarantees about the order in which the methods will be called.

So if your data shapes go through { a: string, b: null, c: null } -> { a: string, b: string, c: null } -> {a: string, b: string, c: string }, the type system doesn't know it; it will assume that { a: string, b: null, c: string } is valid too (which goes against the "make illegal states unrepresentable" principle).

Alternative approach

As usual: inline it? :)

I mean something like this:

person = {
  initialPerson = getPerson()

  gender = pick(mx(0, 1)) > 0.5 ? "Male" : "Female"

  expectedLifespan = ...(gender, ...)

  // with spread syntax this would be just { ...initialPerson, gender, expectedLifespan }
  Dict.set(Dict.set(initialPerson, "gender", gender), "expectedLifespan", expectedLifespan)
}

Here, the order of statements expresses the dependencies between steps, so types are guaranteed to be correct.

This is how I would write this code even in JS, instead of mutating the original person object.

[OAGr]

To be clear, I'm inlining it now. The problem is that this can get messy as your data structure becomes more complicated and the function becomes longer. It works for relatively short/simple cases, but becomes increasingly complicated as things progress.

Also, it's not very flexible. There could be situations where only the gender() is desired, in which case you wouldn't want to also calculate the expectedLifespan.