// 3D Dom viewer, copy-paste this into your console to visualise the DOM as a stack of solid blocks. | |
// You can also minify and save it as a bookmarklet (https://www.freecodecamp.org/news/what-are-bookmarklets/) | |
(() => { | |
const SHOW_SIDES = false; // color sides of DOM nodes? | |
const COLOR_SURFACE = true; // color tops of DOM nodes? | |
const COLOR_RANDOM = false; // randomise color? | |
const COLOR_HUE = 190; // hue in HSL (https://hslpicker.com) | |
const MAX_ROTATION = 180; // set to 360 to rotate all the way round | |
const THICKNESS = 20; // thickness of layers | |
const DISTANCE = 10000; // ¯\\_(ツ)_/¯ |
This document describes the general outcome we want for users as well as a few ideas on how we should do this. It shouldn't be considered prescriptive or precise though; if we come up with better ideas along the way, we should do them instead!
Users should be able to run something like the following:
$ sbt new typelevel/serverless.g8 --branch aws/http
trait Isomorphism[A, B] { | |
def fw: A => B | |
def bw: B => A | |
} | |
object Isomorphism { | |
implicit def anyIso[A](a: A) = new { | |
def as[B](implicit ev: Isomorphism[A, B]) = ev fw a | |
} | |
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) = {
Fibers are an abstraction over sequential computation, similar to threads but at a higher level. There are two ways to think about this model: by example, and abstractly from first principles. We'll start with the example.
(credit here is very much due to Fabio Labella, whose incredible Scala World talk describes these ideas far better than I can)
Consider the following three functions
import scala.slick.lifted.CanBeQueryCondition | |
// optionally filter on a column with a supplied predicate | |
case class MaybeFilter[X, Y](val query: scala.slick.lifted.Query[X, Y]) { | |
def filter[T,R:CanBeQueryCondition](data: Option[T])(f: T => X => R) = { | |
data.map(v => MaybeFilter(query.filter(f(v)))).getOrElse(this) | |
} | |
} | |
// example use case | |
import java.sql.Date |
Lately I have been busy reading some new books on Domain Driven Design (DDD) and software architecture -- including a short yet eye-opening one in Python and a great one in F#. At the same time, it seems that more people in the Functional Programming world are looking at more formal approaches to modelling -- some examples here. This has brought some thought from the background of my brain about how we should model, organize, and architect software using the lessons we've learnt from functional programming.
Before moving on, let me be clear about this being just a dump of some thoughts, not always well-defined, definite
implicit class RichQuery[E, U, C[_]](val underlying: Query[E, U, C]) { | |
/** | |
* To group by elements by some columns, say "column1" and "column2", and then pick latest in each group, you | |
* would normally "ORDER BY column1, column2, created_at DESC" and then "DISTINCT ON (column1, column2)". | |
* However Slick currently does not support DISTINCT ON. There are a number of alternatives that can be used to | |
* circumvent this limitation. The following function uses "sub-select method" described here: | |
* https://robots.thoughtbot.com/ordering-within-a-sql-group-by-clause#sub-select-method | |
* | |
* This function only deals with arity 2. You will need to define variations of it for different arities. We | |
* attempted abstracting over arity but could not get it working. |