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
This project is a tiny compiler for a very simple language consisting of boolean expression.
The language has two constants: 1 for true and 0 for false, and 4 logic gates:
! (not), & (and), | (or), and ^ (xor).
It can also use parentheses to manage priorities.
Here is its grammar in BNF format:
expr ::= "0" | "1"
The idea behind program analysis is simple, right? You just want to know stuff about your program before it runs, usually because you don't want unexpected problems to arise (those are better in movies.) Then why looking at Wikipedia gives you headaches? Just so many approaches, tools, languages 🤯
In this article I would like to give a glimpse of an overarching approach to program analysis, based on ideas from abstract interpretation. My goal is not to pinpoint a specific technique, but rather show how they have common core concepts, the differences being due mostly to algorithmic challenges. In other words, static analysis have a shared goal, but it's a challenge to make them precise and performant.
Code is meant to be executed by a computer. Take the following very simple function:
fun cantulupe(x) = {
| -- Based on: http://augustss.blogspot.com/2007/10/simpler-easier-in-recent-paper-simply.html | |
| import Data.List (delete, union) | |
| {- HLINT ignore "Eta reduce" -} | |
| -- File mnemonics: | |
| -- env = typing environment | |
| -- vid = variable identifier in Bind or Var | |
| -- br = binder variant (Lambda or Pi) | |
| -- xyzTyp = type of xyz | |
| -- body = body of Lambda or Pi abstraction |
ci.yaml into .github/workflows/| {-# LANGUAGE | |
| DeriveGeneric, | |
| FlexibleInstances, | |
| FlexibleContexts, | |
| AllowAmbiguousTypes, | |
| ScopedTypeVariables, | |
| TypeApplications, | |
| TypeFamilies, | |
| TypeOperators, | |
| PartialTypeSignatures, |
| # Using a specific checkout of nixpkgs makes it easy to debug as you know exactly what the deps are. | |
| # This being said in production you should pass the global nixpkgs to this file. | |
| let nixpkgs-src = builtins.fetchTarball { | |
| url = "https://github.com/NixOS/nixpkgs/archive/56d94c8c69f8cac518027d191e2f8de678b56088.tar.gz"; | |
| sha256 = "1c812ssgmnmh97sarmp8jcykk0g57m8rsbfjg9ql9996ig6crsmi"; | |
| }; | |
| in | |
| { pkgs ? (import nixpkgs-src {}) }: | |
| with pkgs; | |
| with stdenv.lib; |
| module RedBlackTree | |
| ( | |
| Tree, | |
| empty, | |
| member, | |
| insert) | |
| where | |
| data Color = R | B deriving Show |
Table of Contents
I think Gabriel's blogpost http://www.haskellforall.com/2018/08/nixos-in-production.html he explains how to work around nixos-rebuild's inflexibilities. However, I think everything that is being suggested is actually possible in nixos-rebuild already
They blog is still a good exercise to understanding what nixos-rebuild does behind the scenes though.
Deploy to a target machine, from a build machine, with pinned nixpkgs, and a specific nixos config:
nixos-rebuild switch \
--build-host=build@build.service.consul \