Every once in a while I investigate low-level backend options for PL-s, although so far I haven't actually written any such backend for my projects. Recently I've been looking at precise garbage collection in popular backends, and I've been (like on previous occasions) annoyed by limitations and compromises.
I was compelled to think about a system which accommodates precise relocating GC as much as possible. In one extreme configuration, described in this note, there
| (* The syntax of our calculus. Notice that types are represented in the same way | |
| as terms, which is the essence of CoC. *) | |
| type term = | |
| | Var of string | |
| | Appl of term * term | |
| | Binder of binder * string * term * term | |
| | Star | |
| | Box | |
| and binder = Lam | Pi |
在近代高等程式語言快（ㄏㄨˋ）速（ㄒ一ㄤ）演（ㄔㄠ）化（ㄒㄧˊ）的狀況下，很多 strong type 的程式語言都開始有了 generic 的設計， 舉例來說：
（這只是大略分類）
- Mobile: Swift, Kotlin
- Frontend: Flowtype, TypeScript
- 後端語言：Python (pyre), Scala, C#, Java （沒錯！現在連 Java 都有）
| {- | |
| A program searching for solutions of a board puzzle | |
| given by a friend. | |
| The aim is to fill in a 8 by 8 square using the | |
| given 8 pieces. Each piece has a particular shape and | |
| can be rotated and flipped. | |
| I am not satisfied with this program yet. The program |
First off, thanks for all the comments and kind words on the original writeup; I've been meaning to follow up on some of the suggestions and write about the different ways to represent monads (and functors, HKTs, etc) that now exist, but a month of being busy has kind of gotten in the way (mainly with three new kittens!).
And for sure, I do not expect (nor do I want) this to become the norm for production-level Rust: rather, I hope that this can contribute to the foundations of programming with higher-level abstractions in Rust, somewhat like how early template metaprogramming in C++ and typeclass-constraint-unification metaprogramming in Haskell have contributed, perhaps indirectly, to later innovations in their respective languages and ecosystems that were much more reasoned, sound and usable.
One of the things suggested in the com
| var USELESS_PROPERTIES = []; | |
| function processContainer(container) { | |
| if (container instanceof CSSSupportsRule) | |
| if (!CSS.supports(container.conditionText)) | |
| return false; | |
| if (container instanceof CSSMediaRule) | |
| if (!matchMedia(container.conditionText).matches) | |
| return false; | |
| if (container.media && container.media.mediaText) |
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.
| module Main where | |
| import Prelude | |
| import Effect (Effect) | |
| import Effect.Console (log) | |
| import Data.Ord (abs) | |
| import Data.List (List(Nil), range, (:), length) | |
| import Data.Traversable (traverse) |