Playing With Pointers

An anti-drug article [1] was written and published by some IIT Kharagpur students in one of our campus newspapers. I think the article is rubbish and here's why.

I think the article should, in principle, offend any self-respecting individual due to its tone and any rational person due to the "facts" it presents. From this point on, I tacitly assume that people reading this anti-(anti-drug-rant) rant posses both rationality and self-respect to some extent.

One interesting thing about the article is that after replacing "drug use" with "gay marriage" the reasons still remain "valid", and become strikingly similar to what anti-gay lobbyists routinely come up with. The illegality of two men loving each other, the separation from normal society, "underground" gay groups and "the gateway effect". One of the reasons routinely cited in support of anti-gay laws is that if we allow two women to marry, men will start sleeping with dogs and sisters will engage in incest. Needless to say, such fears are as baseless as the gateway drug theory [2] the authors talk about.

Perhaps the most objectionable aspect of this article the way the authors instruct their reader on the "right" way to lead their lives. Whether someone spends their free time reading Shakespeare or worshipping bananas is entirely for themselves to decide. Advice can only be given conditionally, "If you want to be an astronaut eating zombie then do the following ... ", or in this particular case "If you're giving advice to self-respecting people ...". Unconditional advice speaks poorly of how the author view people around them even more poorly of TSA for publishing such an article.

Getting down to the factual aspects:

It is true that most nations ban drugs, but more and more countries are taking steps towards legalization. London [4] is re-thinking their drug laws and Portugal decriminalized drug use [5] over a decade ago. In our own country we have licensed Bhang Shops [3]. Cocaine and heroin were both legal for several decades -- does it mean it was "okay" to use them back then? The issue is, legality isn't always a good indicator of whether a particular activity is harmful or not. Even practically, the only country I have heard of where such drug-laws are strictly enforced is the US of A, and I don't think the reader will need to be told that their notion of what to "fix" and what not to is a bit skewed. Personally, no one in my social circle ever got into any legal trouble for smoking up once in a while.

The authors mention legality again, and their argument is flawed for the reason already mentioned. Going by this logic, DC++, anything but regular sex, homosexuals (in West Bengal) should all be avoided.

Keeping secrets from some people is not the same as getting disowned from society. Moreover, people choose friends and social circles based on their opinions, not the other way around

You can't vote in this country if you mind sponsoring corruption. :) Plus, at least in West Bengal, marijuana is grown locally by extremely poor people. If anything, by buying pot you're ensuring they have enough to eat for a day.

I agree with the authors on one thing and one thing only -- presenting a distorted picture of drug use, mentioning the good while leaving out the bad and risky is never ethical. In fact, I find this article unethical for doing the exact opposite, which is just as bad.

Fact is, however the authors try to pretend to be omniscient beings who transcend time and space, they're are just like the readers they're trying to advise and I don't think they know any better. People have a right to choose what they do with their lives; giving out unsolicited advice is vulgar and revolting.

Does this mean I condone drug usage? Well, it doesn't matter what I think. Drugs can ruin your life, be the most meaningful experience you take out of this phase of your life or just something you do once in a while. Your life is yours to make and destroy, and I don't get a say in it.

PS: This isn't a personal attack against anyone.

PPS: I don't contribute to any multiple-continent-spanning newspaper.

--

[1] http://www.scholarsavenue.org/2012/03/17/an-open-letter/
[2] http://en.wikipedia.org/wiki/Gateway
[3] http://en.wikipedia.org/wiki/Bhang
[4] http://www.telegraph.co.uk/news/uknews/law-and-order/4581743/Now-Home-Office-drugs-adviser-wants-to-downgrade-LSD-from-A-to-B.html
[5] http://www.huffingtonpost.com/2011/07/03/portugal-drug-laws-decriminalization-_n_889531.html

I recently had occasion to screw around Haskell's type system. The end goal was to produce a Tic-tac-toe game in which all type-correct moves are legal and where all illegal moves produce type errors. I decided call the following moves illegal

• attempts to move on a cell already occupied
• attempts to make a move on a game that has already been won

While it does not make sense to compile the program into an executable the game is quite "playable" from the ghci REPL. The code is up on github [1].

In fact, Haskell's type system, with the UndecidableInstances extension is Turing complete, so it isn't a surprise that such a thing is possible. But type level programming has its own set of rules and I had a lot of fun figuring things out in such a foreign domain (Type-Level Instant Insanity [2] was extremely helpful). This post is about some of the things I observed.

Tuples are the type-level lists

This seems obvious now that I say it, since a tuple is the most straightforward way to represent a list of types. However, the direct way to do so is not very useful -- instead of encoding the types A, B, C as the tuple type (A, B, C) it is clearer to represent them using the usual recursive cons idiom: (A, (B, (C, ()))). Here () is the nil element and cons X Y is (X, Y).

Functional dependencies

Haskell normally doesn't allow typeclasses on more than one type. Adding proper functional dependencies can fix this [3]. A multi-parameter typeclass is essentially a n-ary relation between types and a functional dependency constrains the relations that a multi-parameter typeclass can represent. This has interesting consequences when programming with types.

The functional dependency in X a b c | a b -> c constrains the relation it defines by forcing c to be a function of a and b. This can be used to defined type-level functions. Specifically, a function that maps two types to a third type can be represented just like the typeclass X in the example above. The body of the function can then be defined as a bunch of instance declarations. If you're doing something like Peano arithmetic and representing, for instance, 2 by the type S (S ()) (S is a type constructor here), you can implement addition as shown below:

{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies,
             FlexibleInstances, UndecidableInstances #-}
 
data S x
 
class Add x y z | x y -> z where add :: x -> y -> z
instance Add () x x where add = undefined
instance (Add x y z) => Add (S x) y (S z) where add = undefined

The functional dependency in Add states that the output of Add is a function of the first two types, which is correct. Note how we're building up the induction.

I had a hard time figuring out how predicates like "two things are foo if they are not bar" are to be represented. The reverse was easy, you use a context -- instance (Foo x, Foo y) => Bar x y, but there isn't any way in Haskell to say instance (NOT Foo x, Not Foo y) => Bar x y. If you think about it, there is no reason to have such a feature either -- the only reason for saying "if x is in the typeclass X then it is also in the typeclass Y" is to be able to use X's functions in defining Y's, so having "x is not in the typeclass X" in the context is absolutely useless! The solution (which I read in [2]) is to instead have such predicates "return" a type (which is a value in this weird world we're working in). For better readability, defining two types, data T and data F for this purpose is useful. [1], for instance, is littered with instances like

-- When a is X then it isn't Y and vice versa.  Silly example, but I
-- think it demonstrates the point
 
instance (X a T) => Y a F
instance (X a F) => Y a T

Inverted Induction

Finally, the way you write "function bodies" at the type level is a bit different. Instead of breaking down a function into smaller bits and then recursion on those, you conditionally build smaller structures into larger structures. For instance, to check if an element is in a list, you say "if the object o is in a list l or if x == othen it is in the list cons x l for all x". It isn't any different really, once you get used to it.

--

[1] https://raw.github.com/sanjoy/Snippets/master/TicTacToe.hs
[2] http://www.haskell.org/wikiupload/d/dd/TMR-Issue8.pdf
[3] http://www.haskell.org/haskellwiki/Functional_dependencies