Saturday, November 17, 2007

I think we believe too much, without really doubting. Without questioning. Why is something this way and not another? Why is this the valid interpretation, not another? For any given observation can we only make a finite number of hypothesis?

Too little doubt. Too much taken on faith. Science is a culture of doubt. Too little science. Why is monadic computation pure? Why are term algebras and inductive definitions pure? What is pure? What are effects?

 

I really like this snippet:

Richard Feynman, in lecture talking about how to create a new law in physics. 1964.

A small follow-up clip:

http://www.youtube.com/watch?v=d1ZtRN-iGdQ&feature=related

Saturday, November 17, 2007 1:10:17 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
 Tuesday, November 13, 2007

If anyone finds this blog entry - dont drive yourself mad trying to get package installation to work through the menu for Xemacs on Vista. Essentially, if you try to do it, it complains with the comment:

WhatAPty

ftp anonymous@ftp.xemacs.org seems not a pty. Kill?

Exactly what could that mean? Maybe it means "Serve the Bud Lite, dooode... ". What a Pty! If you search for it you will get some amazingly contrived "solution" suggestions out there. Some of them involve installing cygwin, getting lftp or ncftp under cygwin, setting it up on your path and getting Xemacs to use one of them.

After wasting lots of time, I must say - its not worth it. Nothing worked. Not even getting the new beta XEmacs-21.5-b28 as opposed to the stable version XEmacs-21.4.21. Nothing worked.

The long and short of what I have to say is, dont bother. Just install the packages you need by hand. Its much easier than you think.

Go here to download the package you need -
http://ftp.xemacs.org/pub/xemacs/packages/

Then simply follow the instructions here.
http://www.xemacs.org/Documentation/packageGuide.html#Installing_by_Hand

Here is the relevant part:

Installing by Hand

Fetch the packages from the FTP site, CDROM whatever. The filenames have the form name-<version>-pkg.tar.gz and are gzipped tar files. For a fresh install it is sufficient to untar the file at the top of the package hierarchy. For example if we are installing the 'xemacs-base' package in version 1.27:
mkdir $prefix/lib/xemacs/xemacs-packages \ # if it does not exist yet
cd $prefix/lib/xemacs/xemacs-packages
gunzip -c ...../xemacs-base-1.27-pkg.tar.gz | tar xf -

For MULE related packages, it is best to untar in the mule-packages hierarchy, i.e. for the mule-base package, version 1.25
mkdir $prefix/lib/xemacs/mule-packages # if it does not exist yet
cd $prefix/lib/xemacs/mule-packages
gunzip -c ...../mule-base-1.25-pkg.tar.gz | tar xf -

That's it, just extract the package file into the folder!

I just installed ocaml support, and it just worked! I cant understand why its so hard to get this right in the menu. Grrr.... But then again, the sum total number of things I cant understand this is just one of the simpler ones.

Tuesday, November 13, 2007 10:46:42 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
 Sunday, November 11, 2007

Yesterday I went out to the the Union and bought myself a copy of Windows Vista Ultimate. My laptop is a Dell Inspiron, has a 1.7GHz Intel processor, 1 Gb or Ram and several external hard disks. The student license costs me ~20$, roughly the cost of two dinners. Vista roughly rates performance as 3.6 for my machine - the bottleneck being my processor speed.

I had heard several conflicting opinions about the OS, most being negative. I finally decided to try it to find out. I must say that in the past day or so my experience has been mostly pleasant. As a matter of fact the OS is yet to do anything to upset me very much.

Yes it is slightly slower than XP on my machine (my previous 2 year old XP setup had degenerated to crawl, so in cases it is actually faster than XP). Despite being slower it is not too frustrating as they have taken care of a vast number of small details, that makes the system more pleasant to use.  The weather gadget for example means that I don't have to use that piece of bloat from weather.com. Outlook actually seems to start a little more promptly on this OS.

Things like the fact that the OS asks about privilege escalations is rather nice. Even other things, like the fact that they did something as goofy sounding as brining your systems performance down to a single number makes a it rather handy. Most of the time people ask things like, "I have this hardware and this setup... will the following software run on it", now there is some heuristic with which you can come to an answer without relying on your local bullshit-expert. This is all entertaining and daresay, even useful.

I like the Aero look. I like the Win+Tab combination. I like the fact that they don't run the indexer all the time and bog down the system like they do on XP. I like how access control and such is better integrated into the UI. A better file copy interface finally. It also seems like there are some scheduler hacks to better prioritize interactive and foreground processes. Altogether a nice package.

Kudos Microsoft! I was truly skeptical and I had my XP installer handy. Now lets see how all this hold out for a few months.

Sunday, November 11, 2007 7:10:40 PM (Eastern Standard Time, UTC-05:00)  #    Comments [2]  | 
 Tuesday, November 06, 2007

This Sunday, Kyle, Michael and I were enjoying a little late morning brunch at the lovely Le Petit Cafe and some light banter about polymorphic lambda calculi. Patrick would occasionally swing with his strange stories, narrated with his uniquely French mannerism. Joie de vivre!

Thus passed a nice Sunday morning when I see a little girl walk up to me. She is short, about 3 foot tall, not quiet opaque and is wearing a bright red cape and hood. She stands by my side, next to our table, and listens to us for a bit. Kyle and Michael were chatting about Kinds and Sorts. Then she says to me "What strange conversations you have Grandma". I say, "The better to understand them with, my dear". I expect her to scamper away, doing whatever it is that she needs to do, but instead she stands there, her large luminous eyes locked in mine. All this starts to get very irritating and I'd wish she would just buzz off when Kyle asks me something. I turn to reply mumbling that maybe I should eat her or something, that way she'd go away. Kyle asks me what I mean. I explain. The two of them suddenly get unnecessarily excited. "You hold him down. I will run for help". Groan...

Thinking back about it, I wonder if the wolf ate her simply because she was so annoying. After all, ignoring rumors, he was trying to get some sleep and there comes this pest asking all these inane questions.

Tuesday, November 06, 2007 1:13:19 AM (Eastern Standard Time, UTC-05:00)  #    Comments [2]  | 
 Monday, November 05, 2007

Sometimes you've got to scratch an itch. So here goes:

X-Zylo
http://www.xzylo.com/
http://www.youtube.com/watch?v=-GavWPxAAlY

GyroBall: A Japenese Baseball Pitching technique
http://en.wikipedia.org/wiki/Gyroball

Dyna Flex Gyro Ball Gyroscope
http://www.youtube.com/watch?v=nC5AjM2NI_c

Stirling Engine
http://www.gyroscope.com/catalog.asp?catalog=1014
http://www.youtube.com/watch?v=vM0YmlRIYBI

Gyroscope
http://www.youtube.com/watch?v=9WbbfzMH2to

The Controversy generating Royal Institute talk by Eric Laithwaite
http://www.gyroscopes.org/1974lecture.asp
(Its a bit funny actually)

XStream: Internal Wing Aircraft
http://www.rexresearch.com/carrcoan/carrcoan.htm

Winshurst Machine (Voltage Generator)
http://www.physlink.com/estore/cart/WimshurstMachine.cfm

Maxwell Wheel
http://www.physlink.com/estore/cart/MaxwellsWheel.cfm

Levitron
http://www.youtube.com/watch?v=iv8msBamA3M

Radiometer (Light Mill)
http://www.youtube.com/watch?v=6Zd70sOcYOQ

 

Got more?

Monday, November 05, 2007 11:35:42 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
 Saturday, November 03, 2007

I get irritated because too many people in the "computing" business don't understand the word "lambda". Its just irritating because at the heart of it, its just a simple fundamental idea, like the notion of natural numbers or counting. So just spend a few minutes, understand what it means and stay educated. In a few years (if not already), almost every language is going to expose something like a lambda to its programmers. So just pick up the idea ok?

This is a working description, it wont make you an expert on the Lambda Calculus. It might give you some intuitions about it though. Lets get started.

So assuming you are familiar with a C-like language, how do you write a function that takes an integer and returns it?

int foo(int x) {
    return x;
}

Now lets look at what this is saying, it says there is a function called foo, it takes an int which it names x and it returns an int. the body of the function has a single statement called return x. Great! Now, this function is a very famous one and is called the identity function (usually goes by the nick-name id). Also when we talk about functional programming we dont really care very much for the C-style types. So let's rename the function and drop the types.

id(x) {
      return x;
}

Don't worry too much about the types. Typed functional languages usually have a different notion of types from the C like languages. The types will come back, but in a bigger and better form. We however wont discuss any type theory in this article.

So now, what it is saying? It says here is a function called id, it takes some value that it calls x and it returns x. Ok, now lets take a look at this closely. In the syntax that we have here, the name of the function is part of the syntax. We would like to say - here is a function and then assign it the name id. So that we are able to look at the function and its name as two different things. Lets do that by introducing the keyword called "function". Javascript, for example, has such a keyword.

id = function(x) {
      return x;
}

Ok. Now lets make one more simplification. Lets say that the language is a little like Ruby or so where that last statement in a functions body is its return value. Did you get that? That means that we no longer need the keyword return. We can simply make the last statement x and by that we know that the return value from the function will be x.

id = function(x) {
      x;
}

Great, lets rewrite this a bit:

id = function(x) { x; }

Now for one more simplification (really C like languages are so complex!) - lets assume that we can write only one statement inside each function. Just one. If that's the case it can be much like a if with just one statement - we don't need the curly braces anymore. We also don't really need the semicolon.

id = function(x) x

Great! Congratulations ladies an gentlemen, you are looking at a lambda. Simply rename the keyword function and call it lambda and we are all set.

id = lambda(x) x

If we drop the name assignment and look at it we have:

lambda(x) x

This is a function that has no name. It take one argument and return it. Various functional languages use slightly different syntax for writing out their lambdas. The lambda calculus, the underlying calculus of these systems, usually uses a \ instead of the verbose name lambda. It also uses a dot to separate the arguments from the body of the function. A little like this:

\x.x

The functional language Haskell uses an arrow to separate the body from the arguments.

\x->x

The language(s) ML, OCaml, SML, (maybe F#) etc. use the name fun to stand for lambda.

fun x -> x

The language Scheme uses the name lambda and lots of parenthesis.

(lambda (x) x)

Ruby lets you write something very similar to a lambda like this:

lambda {|x| x}

Most of these languages give you some mechanism by which you can give a name to your lambdas (otherwise most of the time you are a little hard pressed to refer to them).

Haskell

id = \x -> x

ML

let id = fun x -> x

Scheme

(define id (lambda (x) x))

There are some alternate syntaxes for writing named lambdas in most languages:

Haskell

id x = x

ML

let id x = x

Scheme

(define (id x) x)

So what is a lambda? It is usually a name used to define a function. The function is a value that can be assigned to a variable name. Just like any other value in your language.

A lambda is an abstraction form. Normally in a program you can read the value of a variable to which you have not assigned a value. In other words is you write (x + 1), it does not have any meaning if x has not been assigned a value already. One way to look at what lambda says is that it abstracts the value of the x. So \x.(x+1) means - give me a value for x and then I will give you the value for x+1. The value of x is abstracted in the body of the lambda. This description comes very close to our informal notion of a function in a C like language.

The lambda calculus usually allows only for lambdas that take one argument. Hence to write functions that take multiple arguments we nest lambdas. We write \x.(\y.(x+y)) for a function that adds two numbers. Most functional languages support multi-argument lambdas. In Haskell this would be \x y -> (x+y).

So what's the big deal? Nothing much and quiet a lot. Nothing much because the notion of functional abstraction is something we learn from high-school math which we port over to programming languages. This is an old and familiar notion.

That said, in the functional programming community, it has long been realized (it is a large community with varying beliefs, secret cults, traditions and practices) that lambdas are the only abstraction form required for a lot of things.  One can do away with loops and conditionals (if, switch) and assignments and numbers and object oriented programming and pretty much everything you can think of (and some things you cant) - they can all be encoded using lambdas. Hence lambdas form a sort of foundational building block for a large number of programming paradigms. At the heart of all of this is the notion of a function - hence the name functional programming.

Saturday, November 03, 2007 6:03:52 PM (Eastern Standard Time, UTC-05:00)  #    Comments [1]  | 

One of my long standing irritations with Haskell is that there is no real way to generate fresh names if your code is non-monadic. Haskell is a fairly "pure" side-effect free language. Hence when you write interpreters and such in it, and you need a new name for something (say a new variable name), there is no way to generate one.

The normal (and correct) solution for this is to write your code in a State monad of some sort and pass a counter around. Every time you need a fresh name you retrieve the counter, increment it, update it and such. This is all very well, but it brings the baggage of the monadic syntax with it. It would be nice to be able to retain direct-style syntax and have fresh names.

Often when you want to test an idea, the clutter of fresh name generation simply gets in the way. Generating fresh names is essentially an effectful operation, which is essentially why Haskell does not allow it. All effects should be made explicit in the types of terms in Haskell.

Using the hack for fresh names below you side step this requirement. The direct consequence of this is that your code suddenly becomes effectful. It is no longer pure. Writing code that relies on fresh names does not automatically mean that code has a purely functional representation in the obvious way.

The other down side is that code written using fresh name generation may not even work correctly in GHC most of time. This is because GHC assumes that there are no side effects in your code. Hence it freely moves code around and does common sub-expression elimination. To clearly see what this means, consider a pure function that computes the 100th prime number. The function takes no arguments and returns a prime number to the caller. If the function is called from 5 different parts of your program, the sharing semantics of lazy evaluation ensures that it is only computed once (if at all). Subsequent calls, simply use the previously computed value.

Now imagine you write a function that returns a fresh name. If GHC decides that the function does not need to be re-evaluated, in every context where the function is called the original computed value will be returned. This means that you will get only one name ever and this is not what you want. In other words adding fresh names breaks "referential transparency".

Hence writing code that uses fresh names, as defined here, without any direct support from the compiler, is inherently at risk from various compiler optimizations. Use it based on your judgement of things. (Don't use it for the the next missile guidance system even if you think you know what you are doing. )

module FreshName(Opaque, freshName) where
-- Generate FreshNames hack
-- Roshan James, Nov 2007
 

import Data.IORef
import Debug.Trace
import Foreign

data Opaque = Opaque Int
              deriving (Eq, Show)

freshCounter :: IORef Int
freshCounter = unsafePerformIO $ newIORef 0

freshName :: (Opaque -> a) -> a
freshName f = unsafePerformIO $ do c <- readIORef freshCounter
                                   writeIORef freshCounter (c + 1)
                                   return (f (Opaque c))

In the above module, Opaque is the type of a fresh name. The Opaque data type cannot be inspected by consumers of the module. The only operation that's defined on Opaque is the equality test i.e. Opaques can be compared to each other, but cannot be used for anything else. For convenience  I have defined a Show on Opaque as well for pretty printing, in the absence of which one would need to have a lookup table to correctly display Opaques.

In some senses freshness is a strange effect. It is an effect that breaks (programs change their results) in the presence of sharing or code motion. It is completely impervious to order-of-evaluation unlike state, control operations, jumps, exceptions etc - we can switch the order of reductions any way we like and the semantics of the program is preserved.

The general rule, to my best understanding, is this: If the type of a term exposes the type of the fresh name then the term cannot be freely shared. It is not a referentially transparent term. When I say the type exposes the Opaque type, I mean that some sub-term of the type is the Opaque type or is defined in terms of the Opaque type. Terms that do not expose the Opaque type, but potentially uses them internally, are referentially transparent. Maybe this insight can form a good intuitive guideline for writing code in GHC using fresh names. 

Here is an sample usage of the fresh names module. I define an alpha conversion function using it:

substitute :: Var -> Var -> Exp -> Exp
makeVariable :: Opaque -> Var

alphaConvert :: Exp -> Exp
alphaConvert (Lam x e)  = freshName $ \op ->
                         let x' = makeVariable op
                         in (Lam x' (substitute x x' e))

Drop me a note if you find this useful or if you have a better technique.

Saturday, November 03, 2007 1:18:43 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
"We spend our whole lives in unconscious exercise of the art of expressing our thoughts with the help of words."
          -- Vincent Van Gogh
Saturday, November 03, 2007 9:49:18 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  |