Author: Varun Gandhi (@typesanitizer)
Compilers generate assembly in the penultimate stage of compilation.
The assembly is processed by an assembler, which generates machine code for subsequent processing by a linker.
-- run with | |
-- stack ghci --package lens --ghci-options="-XDeriveDataTypeable" plate.hs | |
{-# LANGUAGE DeriveDataTypeable #-} | |
import Data.Data | |
import Data.Data.Lens | |
import Control.Lens.Plated | |
data E |
(Note to the reader: Sections marked with < VG: ... > are notes inserted by me | |
(Varun), not from the original author. I'm just taking notes here to understand | |
better what exactly the person wants, and trying to analyse how the different | |
"requirements" are at odds with each other.) | |
The question was asked why I (as a programmer who prefers dynamic languages) don't consider static types "worth it". Here | |
is a short list of what I would need from a type system for it to be truely useful to me: | |
< VG: This is dangerous to some extent (if you use it everywhere). History | |
has shown that while people (e.g. ML/Haskell users) were initially interested |
Note: This is for my personal projects so I can maintain a consistent style, not for other projects.
Rust code should follow the same guidelines of organization and naming, but the 'MARK:' prefix isn't recognized by editors other than Xcode, so it should be skipped.
Types and associated methods should be grouped in // MARK:
blocks as follows:
Here is a list of resources that I have read either fully, or at least to an extent with which I am comfortable with endorsing them.
I've used these resources in different ways:
Recently, I posted the following poll on Twitter:
Say iterating over a hash table gives non-deterministic results. So you iterate over it, store the key-value pairs in an array, and do a stable sort. Is the sorted result deterministic? (assume no bugs in the implementations of sorting, iteration and that ≤ is a total order)
A: Yes B: Not necessarily
I later clarified that the hash table gave you unique keys. And that the ≤ operation was applied to (key, value) pairs, with the natural interpretation that it would first compare the keys and then the values.
I'm also implicitly assuming that the equality check implied by ≤ is the same as the equality check used by the hash table, as a sensible default.
Analysis of sampling doxygen (pid 13876) every 1 millisecond | |
Process: doxygen [13876] | |
Path: /Users/USER/*/doxygen | |
Load Address: 0x100000000 | |
Identifier: doxygen | |
Version: 0 | |
Code Type: ARM64 | |
Platform: macOS | |
Parent Process: debugserver [13885] |
# Alloy forum post: https://alloytools.discourse.group/t/is-it-possible-to-group-container-nodes-in-the-visualizer | |
# | |
# I usually paste the GraphViz to sketchviz.com. The details are hard-coded | |
# to the specifics of the model, but shared in the hope that the overall | |
# structure of the parsing and printing is potentially useful. | |
# | |
# See example diagram at: | |
# | |
# https://twitter.com/typesanitizer/status/1551575106194878464?s=20 | |
# |