Memoirs of a PhD student

Now have slicing working over matches:

consider:

h :: Int -> (Int, Int)
h y = result 2
where
bob = 42
result x = res 3
res k = (23,24)
bill = 24
h x = (x, x+1)

this creates:

h1 y = result 2
where
res k = 23
result x = res 3
h1 x = x

h2 y = result 2
where
res k = 24
result x = res 3
h2 x = x + 1

Of course the question now is what does the slicer do for recursive definitions? such as splitAt?

Also the pretty printer has gon e abit dodgy in the at does not preserve the declaration order of the new matches... but this seems to type check.

After a couple of months of being absent from my blog, I feel its a good time to start updating again. I also feel this is going to be a bit of a lengthy update. Quite a lot has happened in the last couple of months or so since I last updated.

I have:
-> Submitted papers to the postgrad (including poster) and Haskell Workshop conferences.
-> Ported HaRe to use the GHC type checker.
-> Implemented the splitting definitions refactoring.
-> Completed the add constructor to data type refactoring.
-> Done lots and lots of background reading.

I have just had my panel review today. Basically Olaf and Andy were pleased with the progress I had made since the last review. They said, although I had a slow first year things were really starting to move forward and I was starting to become very involved in the work. However, I need to look into fewer areas in more detail. Instead of chossing lots of refactorings to implement, it would be better to pick a specific one and concentrate on formalising and writting a prrof for it. In particular the program slicer.

Olaf commented that it would be a useful exercise to write up the work I had done on using Programatica and GHC-API. It would be a good idea to put the write up on my home page.

I need to make Huiqing's thesis my Gospel. In particular the section on the her theories of formalising refactorings.

In general I need to start writing up implementation and concentrate on just the program slicing. Working towards a formalisation and a proof. Perhaps neglect the merging stuff.

I also need to aim at getting 2 more publications done. Preferably, submitted before February next year.

I think I did OK, but I am left wondering whether what they said was positive or negative. I also regret my first year. But there is nothing I can do about that now. I am wondering whether I am going to finish within 3 years. I guess the challenge is to aim to do so.

I have written a simple program using the GHC API, which outputs the following for a simple module...

Fish.f [T] :: GHC.Num.Integer
[]
{ lit_auR = fromInteger 1
fromInteger = GHC.Num.fromInteger GHC.Num.Integer $dNum
lit_auQ = lit_auR
+ = (GHC.Num.+) GHC.Num.Integer $dNum
$dNum = $dNum
f = 1 + 1 }, $dNum = GHC.Num.$f3

That uses the pretty printer - so now I need to work out the data structure that GHC is using for its AST and then extract the information from it and map it into Programatica's AST.

At last I have ghc 6.5 built, installed and working on my iBook. I finally got it to work by hacking it to bits so that ghc used its native assembler istead of the evil mangler and gcc. This means that the executable that ghc 6.5 produces won't be as optimised as usual, but I'm not that bothered about this. I have tested it with a simple program that uses the API to set up a small project and do some general printing out status stuff. I'll have a play tomorrow.

I'm annoyed that this, along with lots of marking this week has put me behind schedule on my research a few days. In the process however I have learned a lot about GHC - and I am guessing that the problem I am having with perl is not hardware but something to do with faulty locale information. Now I have ghc working and I know how to get around thisl its not too much of an issue any more. I'm just so pleased its finally working.

Now its time to leave the office and have the night off.

I havn't updated my blog for a few days - so I thought an update is in order.

Last week was a bit of a messy week research wise. I played around quite a bit with Template Haskell to discover that it is a really nice tool for source to source program transformations. I managed to write some simple refactorings using it in a few hours. I was surprised at how easy tree traversal is, I expected to write a lot of boilerplate code. The GHC AST is not multiple typed like the Programatica AST is, so I didn't need to use Strafunski.

Chris Ryder and I had a brief discussion about his work on porting HaRe to GHC, and it seems that a nice fix to get around the clumsy and slow type checker that Programatica provides by using the GHC type checker. This would require having a "Programatica land" and also a "GHC Land". Both "Lands" are kept in sync with the refactoring project and the GHC API is only called to get type information, and then the type information is mapped over the Programatica AST. A nice hack I would say. This means that HaRe would basically require GHC 6.5+ to be bolted onto the side, but I think that is a minor issue.

Using GHC in this way would allow for much faster type checking, and make my life easier. However its never simple. GHC has given me nothing but hassle on my Mac, and it has something to do with the evil mangler. Whenever I try to compile source code with the -fvia option set, non-deterministically the compiler fails. Interestingly, it always fails at the point of the evil mangler or the assembler. Something is not right with the system, and after endless reinstalls of Mac OS and memory tests that took all of the weekend I'm still no further forward. Wolfgang doesn't seem to know anything about this, and generally it seems I'm the only guy in the world that has seen this error. Perhaps it has something to do with 10.4... What I need is someone with an iBook G4 running Mac OS X 10.4 so they can check GHC for me.

Today I need to mark some Java assesments and then get my head down and do some research, the lastc few days have put me off course a bit.

Yesterday I gave my TCS seminar. I think it went alright, I got a nice discussion going and managed to answer all the questions. Olaf gave me some constructive feedback about some of the slides. I think next time I won't use LaTeX, its too cumbersome and awkward to get it the way you want. Next time I am just going to use keynote.

Been playing around with Template Haskell today and I have managed to write some simple transformations. I even implemented a simple "refactoring" to convert a data type into a newtype in about 5 or 6 lines of code. I need to think of an interesting example to give in my talk. I have read through "template meta programming for Haskell" by Peyton Jones and Sheard. Later I am going to read an interestig paper about using Template Haskell to create a simple Tetris game.

I have been encountering some strange behaviour in ghc, but it now seems to be fixed thanks to Chris Ryder. Apparently, the latest GHC likes to use GCC 3.3, and I was using gcc 4.0.

Bizzarre - but it works. I thought it could be because I had bad RAM but after running an exhaustive test that took about 6 hours (ran all night) it passed.

Fixed the problem with the type checker adding in the extra parameter to functions that do not return Ints. I should put these in the tped API together with a collection of useful functions that would would with type information.

I have corrected the problem I had last night, and now the refactoring will always try and place the pattern in the case expression. I think this is more suitable. Also this is strange and I can't work out why the type checker is doing this.

Suppose I have the function (without type information)

f (Con1 x) = 34

then the typechecker converts to something of the form...

f d9 (Con1 x) = 34

it puts an extra pattern in for some reason and it only does this if the function has no type signature and it returns an Int.

I have just finished the first version of my refactoring which uses type information to check which functions need pattern binding. This means you can have the declaration:

f :: New -> Int
f x = 45

and the refactoring will add

f :: New -> Int
f (Con2 x) = addedCon2
f x = 45

I have found something very fascinating:

ht (Con2 a b) = addedCon2
ht x
= case x of
(Con1 y) -> y
_ -> 44

In the above example the refactoring added the pattern at the top level declaration, because x is of type New. This is acceptable but I feel there is an alternative and that is to add in the case pattern. There are a nember of ways to deal with this:

1) always add to the top level
2) always add to the case pattern (but not the top level)
3) add to both the top level and the case patterns (belt and braces)

1 or 3 are the easiest to implement.

TODO: remove the hardcoded "New" data type!