It is seductive to imagine that effect handlers in an algebraic effect system are not part of the program itself but metalanguage-level folds over the program tree. And in traditional free-like formulations, this is in fact the case. The Eff monad represents the program tree, which has only two cases:
data Eff effs a where
Pure :: a -> Eff effs a
Op :: Op effs a -> (a -> Eff effs b) -> Eff effs b
data Op effs a where
Monads and delimited control are very closely related, so it isn’t too hard to understand them in terms of one another. From a monadic point of view, the big idea is that if you have the computation m >>= f, then f is m’s continuation. It’s the function that is called with m’s result to continue execution after m returns.
If you have a long chain of binds, the continuation is just the composition of all of them. So, for example, if you have
m >>= f >>= g >>= hthen the continuation of m is f >=> g >=> h. Likewise, the continuation of m >>= f is g >=> h.
| // Maps a value inside the square [0,1]x[0,1] to a value in a disk of radius 1 using concentric squares. | |
| // This mapping preserves area, bi continuity, and minimizes deformation. | |
| // Based off the algorithm "A Low Distortion Map Between Disk and Square" by Peter Shirley and | |
| // Kenneth Chiu. Also includes polygon morphing modification from "CryEngine3 Graphics Gems" | |
| // by Tiago Sousa | |
| inline Float2 SquareToConcentricDiskMapping(float x, float y, float numSides, float polygonAmount) | |
| { | |
| float phi, r; |
| import kotlin.coroutines.* | |
| import kotlin.coroutines.intrinsics.* | |
| /** | |
| * Implementation for Delimited Continuations `shift`/`reset` primitives via Kotlin Coroutines. | |
| * See [https://en.wikipedia.org/wiki/Delimited_continuation]. | |
| * | |
| * The following LISP code: | |
| * | |
| * ``` |
| float circle(float _radius){ | |
| // UV from [0..1] to [-1..1] | |
| vec2 uv = (2.0*gl_FragCoord.xy - u_resolution) / u_resolution.y; | |
| // circle | |
| float d = length(uv); | |
| float wd = d * 3.0/u_resolution.y; // <=> float wd = fwidth(d); | |
| return smoothstep(_radius + wd, _radius - wd, d); | |
| } |
| float map(float value, float min1, float max1, float min2, float max2) { | |
| return min2 + (value - min1) * (max2 - min2) / (max1 - min1); | |
| } |
| #include <iostream> | |
| #include <string> | |
| #include <memory> | |
| using namespace std; | |
| /* | |
| * This program has used some C++11 features to get rid of manual memory management. | |
| * | |
| * If you prefer the older C++ version, do the follwing steps: | |
| * 1. Switch all "EvalPtr" to "Eval *"; do the same to "PPrintPtr" |
| #include <iostream> | |
| #include <string> | |
| #include <memory> | |
| using namespace std; | |
| /* | |
| * This program has used some C++11 features to get rid of manual memory management. | |
| * | |
| * If you prefer the older C++ version, do the follwing steps: | |
| * 1. Switch all "EvalPtr" to "Eval *"; do the same to "PPrintPtr" |
| |=-----------------------------------------------------------------------=| | |
| |=-------------=[ 3 Years of Attacking JavaScript Engines ]=-------------=| | |
| |=-----------------------------------------------------------------------=| | |
| |=------------------------------=[ saelo ]=------------------------------=| | |
| |=-----------------------------------------------------------------------=| | |
| The following are some brief notes about the changes that have taken place | |
| since the release of the "Attacking JavaScript Engines" paper [1]. In | |
| general, no big conceptional changes have happened since. Mitigations have | |
| been added to break some of the presented techniques and, as expected, a |