Yassine Elouafi yelouafi

Algebraic Effects in JavaScript part 4 - Implementing Algebraic Effects and Handlers

This is the final part of a series about Algebraic Effects and Handlers.

Part 1 : continuations and control transfer
Part 2 : Capturing continuations with Generators
Part 3 : Delimited continuations
Part 4 : Implementing Algebraic Effects and handlers

So we've come to the core topic. The reality is that we've already covered most of it in the previous parts. Especially, in the third part, where we saw delimited continuations at work.

Algebraic Effects in JavaScript part 3 - Delimited Continuations

This is the third part of a series about Algebraic Effects and Handlers.

Part 1 : continuations and control transfer
Part 2 : Capturing continuations with Generators
Part 3 : Delimited continuations
Part 4 : Algebraic Effects and handlers

In the preceding parts, we introduced the notions of continuations and control transfer. We saw how to capture the current

Algebraic Effects in JavaScript part 2 - Capturing continuations with Generators

This is the second part of a series about Algebraic Effects and Handlers.

Part 1 : continuations and control transfer
Part 2 : Capturing continuations with Generators
Part 3 : Delimited continuations
Part 4 : Algebraic Effects and handlers

Note: initially I planned a 3-part series, but since the current post on undelimited continuations ended up taking

Algebraic Effects in JavaScript part 1 - continuations and control transfer

This is the first post of a series about Algebraic Effects and Handlers.

There are 2 ways to approach this topic:

Denotational: explain Algebraic Effects in terms of their meaning in mathematics/Category theory
Operational: explain the mechanic of Algebraic Effects by showing how they operate under a chosen runtime environment

Both approaches are valuables and give different insights on the topic. However, not everyone (including me), has the prerequisites to grasp the concepts of Category theory and Abstract Algebra. On the other hand, the operational approach is accessible to a much wider audience of programmers even if it doesn't provide the full picture.

	// from https://x.com/Cody_J_Bennett/status/1818025947565584873
	// demo https://jsfiddle.net/cbenn/Las0poyu

	import * as THREE from "three";
	import Stats from "three/addons/libs/stats.module.js";
	import { OrbitControls } from "three/addons/controls/OrbitControls.js";
	import { GLTFLoader } from "three/addons/loaders/GLTFLoader.js";
	import { mergeVertices } from "three/addons/utils/BufferGeometryUtils.js";

	THREE.ShaderChunk.skinning_pars_vertex =

	var $jscomp = $jscomp \|\| {};
	$jscomp.scope = {};
	$jscomp.arrayIteratorImpl = function (h) {
	var n = 0;
	return function () {
	return n < h.length ? { done: false, value: h[n++] } : { done: true };
	};
	};
	$jscomp.arrayIterator = function (h) {
	return { next: $jscomp.arrayIteratorImpl(h) };

	<!DOCTYPE html>
	<html>

	<head>
	<title>THREE.JS WORLD</title>
	<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/three.js/r73/three.js"></script>
	<style>
	body {
	/* set margin to 0 and overflow to hidden, to
	use the complete page */


	{-# Language TypeSynonymInstances, FlexibleInstances #-}

	module Algj where

	import Debug.Trace
	import Data.Maybe
	import qualified Data.Map as M
	import qualified Data.Set as S
	import Control.Monad.Trans.State


	{-# Language TypeSynonymInstances, FlexibleInstances #-}

	module Algw where

	import Data.Maybe
	import qualified Data.Map as M
	import qualified Data.Set as S
	import Control.Monad.Trans.State


	function isGenerator(x) {
	return x != null && typeof x.next === "function"
	}

	function isFrame(x) {
	return x != null && x._type_ === 'call_frame'
	}

	function call(genFunc, ...args) {