View word.diff
diff --git a/word_language_model/ b/word_language_model/
index c4ea458..7ff9b61 100644
--- a/word_language_model/
+++ b/word_language_model/
@@ -81,6 +81,8 @@ test_data = batchify(corpus.test, eval_batch_size)
ntokens = len(corpus.dictionary)
model = model.RNNModel(args.model, ntokens, args.emsize, args.nhid, args.nlayers, args.dropout, args.tied)
+import torch.jit
+model = torch.jit.verify_model(model)
import torch
from torch.autograd import Variable, Function
import torch._C as _C
import sys
class Add(Function):
def forward(self, a, b):
return a.add(b)
def backward(self, grad_output):
View gist:56a87cd1675d037c1d228c33db359c9f
New summary by @ezyang.
The goal of this task is to add a new command `Setup doctest`, which runs the doctest command on all of the modules of each component in a package, in much the same way `Setup haddock` runs `haddock` on all the modules of each component in a package.
There are a number of steps to implementing this:
1. You have to add the boilerplate for setting doctest up as a new command. Grepping for occurrences of haddock should give you an idea for what you have to edit; the key files are `Cabal/Distribution/Simple/Setup.hs`, adding a case to `defaultMainHelper` in `Cabal/Distribution/Simple.hs`, and a new file to actually contain the logic. I'd recommend against putting too many flags into `DoctestFlags` when starting off.
2. The overall logic of the driver should be something like this:
View .vimrc
" Pathogen is good because you can keep plugins together in logical
" units, without blasting them throughout your directory structure.
execute pathogen#infect()
" This just turns on per-filetype plugins. Vim ships with file
" indentation/plugin/syntax rules for highlighting. The highlighting
" is nice. Sometimes the indentation is a bit annoying though because
" it REINDENTS my stupid code when I didn't want it to. It's annoying
" to track down why it's doing that...

| Str.String| Str.Text| Str.Text.Lazy ---| ---| ---| --- Str | ✔| ✔| ✔ Chr | ✔| ✔| ✔ Index | ✔| ✔| ✔ empty | ✔| ✔| ✔ singleton | ✔| ✔| ✔ pack | ✔| ✔| ✔ unpack | ✔| ✔| ✔ cons | ✔| |


Haskell on Windows

These are empirical observations about running Haskell on Windows. If your experiences have been different, I'd love to hear about it.


You'll need to get the

View building.rst

In Backpack, we both typecheck packages with holes (producing only interface files) and compile fully instantiated packages (producing interface files and object files). While doing this, we try to minimize the amount of work the compiler does. In particular:

  1. Any package with holes is typechecked exactly once, in its most general form (with no instantiations). Partially instantiated packages are never typechecked; instead, we just rename the most general interfaces according to the instantiation "on the fly."
View GhcSort.hs
module GhcSort where
import GHC
import GhcPlugins
import DriverPhases
import Control.Monad
import Data.List
import Data.Maybe
import System.FilePath
View ghc-make.rst

How ghc --make works

In abstract, the job of ghc --make is very simple: compute a dependency graph between modules, and rebuild the ones that have changed. Unfortunately, the code in GhcMake is quite a bit more complicated than that, and some of this complexity is essential to the design of GHC:

  • Interaction with GHCi involves mutating process-global state.
View Productive.hs
{-# LANGUAGE Rank2Types #-}
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE InstanceSigs #-}
module Productive where
-- | Productive coprogramming in the Par monad. Based off of