environmentset / hyogwa Goto Github PK

All the functions of hyogwa assume that given generators representing effectful computation are 'fresh' (i.e. never executed after the creation). Therefore, passing around effectful computation that was already evaluated have high possibility to cause unsound results. For this problem, we can help the users not to make invariants by adding invariant checkers that work at development mode.

function* foo() {
  const bar = baz()

  yield* bar
  yield* bar // this can be problemetic
}

As hyogwa intended to be used with bundlers, hyogwa works well with them. However, I've reported and saw some problems of using hyogwa directly in the node/browser environment after compiling the program with tsc. In this issue, I'm going to investigate environments/settings where using hyogwa is hard or impossible and try to find best solution.

The bigger the project expands, the higher needs to test facility grows. It's time to add test facility. which one should we choose?

P.S. we also need to setup simple CI

To provide better functional programming experience, It is important to be compatible with fp-ts (widely used functional programming library armed with de-facto type class and HKT design). Let's investigate what is needed.

The example of unsafeRunAsync uses unsafeRunSync, not unsafeRunAsyn. This seems to be typo, should be fixed with unsafeRunAsync.

To cover use cases where functional programming libraries or pipeline style coding involves, curried version and data-last version of api is needed.

Like react running useEffect hooks multiple times at StrictMode, we can run handler functions multiple times at development mode so that user can notice if there is any effect having no small effect on execution.

currently, effect representations are created like following:

interface IO extends Spec<'IO'> {
  read(): string
  write(text: string): void
}
const IO = createEffect<IO>('IO')

Here, name of effect is repeated 5 times. this makes look of API verbose and makes users be tired of writing name of effects.
Using interface, adding discrimination tag to spec type, having effect representation in variable, mentioning name of spec when creating effect representation seems to be inevitable. But giving name of effect we want to create as string literal seems to be avoidable and I really hope so. let's find a way.

I think it would be convenient if we can use async functions when writing handle functions for unsafeRunAsync.

unsafeRunAsync(main(), {
  API: {
    async getUserName({ resume }) {
      const res = await fetch(/** some api endpoint */)
      const { data: name } = await res.json()
      
      resume(name)
    }
  }
})

While solving #4, I found using Bun is the most simple solution. It has built-in jest-compatible test runner for both javascript and typescript. There is no need to struggle to learn unfamiliar api and no need to setup cumbersome addons for test runners to have compatibility with typescript.

I want to move further, however, I want not only to adapt Bun's test runner but also to adapt whole Bun utilities. Bun is more performant and typescript-friendly than Node.js and npm. With Bun, we can keep things simple and even make things simpler.

Few weeks ago, alpha version of Bun was finally released. It seems to be stabilized. I think now is the best time to adapt Bun in this project. Any opinions?

These words are used in whole project without clear distinction. We need to make it clear the meanings of these words.

Currently, there's nothing at compile time preventing users from not calling handle tactics. I think we can add more restriction by forcing users to return special values which only produced by handle tactics. But I'm also concerning that this would make writing handlers little more complicated. Any thoughts?

type TacticIsCalled = unique symbol // some special type

interface HandleTactics<in ER, in R> {
  resume(value: ER): TacticIsCalled
  abort(value: R): TacticIsCalled
}

type Handlers<E extends Effects, R = never>
  = Simplify<
      UnionToIntersection<
        E extends Code<`${infer S}.${infer C}`, infer P, infer ER> ?
          Eq<P, never> extends false ?
            { [K in S]: { [K in C]: (...parameters: [...P, HandleTactics<ER, R>]) => TacticIsCalled | Generator<Effects, TacticIsCalled > } }
            : { [K in S]: { [K in C]: ER | Generator<Effects, ER> } }
          : never
      >
    >

For practical use of hyogwa, It's really inevitable to implement platform specific effects such as reading/writing DOM, reading/writing file system, fetching remote resources and etc. Let's discuss about this in here.

I think createCodeConstructors is not good name because:

• Code is internally used data type. We should not mention them in front of users.
• Hard to understand the purpose of calling it without understanding the internal design.
• It's too long.

I wonder how other people think about this. Should we rename this function?

What effects are there which we can add as built-in?

I'm thinking of Exception, State, Env(Reader), Logger(Writer), Pure(total of koka) and Partial. I hope to add non-determinism too but it seems not possible to create smooth/natural interface for it now.

Although hyogwa prefers to use statements when constructing complex program, It's still useful for users to provide api that is compatible with pipeline style api. And sometimes, it's better to use pipelines when composition of abstraction is simple.