æʃliŋ, purrepurrocessor @aescling@cat.family

alternatively just use a global size variable; we can abuse statefulness fur the funny

class Monorail {
  #value;
  #size = 1;

  constructor(value) {
    this.#value = value;
  }

  bind(f) {
    const newThis = f(this.#value);

    if (newThis.#size < this.#size + 1) newThis.#size = this.#size + 1;
    console.log(`the glaceon is now ${newThis.#size} meters tall`);
  return newThis;
  }
};

ill accept that typo that's funny

the monorail monad. every time you bind it logs that the shiny glaceon has gotten a little big larger

@monorail you can build an interface around a list such that everything using that interface is purrfurming non-deterministic computations, BUT, if you do arbitrary shit to a list directly, you don’t have the guarantee that that abstraction will make any sense

@monorail yeah, not all use cases fur list make sense as a monad. this is actually why it's impurrtant imo to sepurrate the data type from a monad built around it

@Lady no?

@Lady seems to be working pretty ok fur alpine

@monorail a n y w a y look into monadic parsing sometime it's very cool

@monorail if you ever look into coding a monadic parser with nondeterministic output i think the idea of list-monad-as-parallel-universes might click into place fur you

@monorail the data types are not monads; the data type and the implementations of the wrapper and the runner functions are what constitute a monad. i mention this because i know of two monads on List; similarly, you could feasibly define two very diffurent kinds of monads around lazy evaluation

@monorail as far as the purractical considerations go, yes, you get it, that’s what you use a monad fur

the thing to observe that you didn’t mention is that the interface to this abstraction/contextualization is extremely general, and exactly reusable line-fur-line with other abstractions, which is neat

@akjcv@types.pl five dollars?? im jealous

@girls ​

@girls the big steppies