Memoirs of a PhD student

This morning has been a very productive few hours. I consulted with Huiqing about why addDecl was putting the [ ] in, and it turns out it was because the pretty printer did not know how to print a list of TiDeclI PNT. This is now fixed - and I learned a whole lot about the pretty printer in the process. I also corrected another bug where the type checker always placed every Int expression in a fromInteger application. My refactoring now removes these leaving Int expressions the same as they were before the refactoring took place.

This afternoon I need to catch up on my Haskell marking and I am also going to implement the next step of my refactoring: to select functions which have an argument of the type in question using type information.

Thte last 2 days has been very hectic. Yesterday I came to port my add constructor refactorinng over to use the TI AST instead, and then realised (with horror) that the API only worked over the normal AST.

I then had to create an API which worked over the TI AST, by creating new type synonyms for the TI Exp, Pat and Decls constructors. I then had to copy the AST into a new file RefacTypeUtils and modify it work with the new constructors. This also require modification to refacLocUtils (also copied over to refacTILocUtils).

After all that and more modifications to the TI API to get my refactoring to work I have found something very interesting. Wherever in the program there is an expression of type Int the type checker wraps up the expression in an application of fromInteger expression. And when the API writes the refactored output to the file - lo and behold it also puts this application in its place.

At the moment I can think of some ways to deal with this:

1. Leave it as it is - it doesn't alter the behaviour, the type checker only puts it in to resolve types;
2. Map the normal AST onto the TI AST preserving TI information (therefore removing these from integer applications)
3. Traverse the TI AST to find where ever there is an INT expression and remove the application.

THis is a pain, I have also found another strange perculiarity: My refactoring adds a declaration, and now it adds the declaration with [ ] around it. This must be do with the new TI API playing up over the constructors.

Intriging. I was hoping to have a version of my refactoring completed today which uses type information, but with porting the API and fixing about a million bugs in the port its put me behind schedule.

I spent most of yesterday playing around with the TI AST. Manily getting my head around some of the subtle differences it has with the normal AST. There is not huge amounts of difference...

In general most things are the same except of identifiers which are decorated with type information. Yesterday I wrote a number of traversals to try and get used to traversing the TI AST. In general i created a simple traversal which asks you for a type - and then finds all expression that match that type. I noticed some interesting things:

All Ints are wrapped up in a fromInteger application;
Some times the type information is wrapped up in a scheme (which also includes any contexts and constraints). I'm still testing the consistency of this.

Today I almost died when I copied my refacAddCon file over to the version of the release I have where the type checker doesn't work. It was because I also modified refacUtils - and forgot to copy that over as well

I also realised something quite important. The API is currently defined over the AST and not over the TI AST. I can't see any major problems apart from creating another refacTypeSyn file which creates synonyms for the TI types. And the importing this file when the TI API is needed. I am also freting about the fact that the API might complain about ambigous occurences of Exp (there is one in TiDecorate and one in SyntaxRec). Hopefully I can get a new version of my refactoring working which will look at patterns which are of the type in Question. Ie.

f :: NewData -> Int
f x = 45

without just looking to see if any of the constructors are referenced in the pattern binding. Claus mentioned something interesting about using TH instead of DrIFT to create the instances. An intersting project, something I might have looked into if I had the time. But my concentration is on my research at the moment.

Its so long since I've listened to Chopin....it just melts in your ears.

I have had a productive couple of days. Firstly I checked the first version of my refactoring, but more importantly I got DrIFT to work. Well, when I say I got it to work - I manually created the instances that Strafunski needed for the TI myself. It took a while todo - All of Saturday and most of today. It seems to work and I have created a simple test using strafunski to return all expressions on the program that have the type "Int".

This means that I can now start to incorporate type checking into my refactoring, -somithng that I have been wanting to do for a while. I have learned so much this weekend, I have learned what the instances mean in the DriftStructUtils file, and also the structure of the TI AST.

Last night on the train I had a very productive few hours of work. I managed to implement support for records, and infix contructors, learning lots about the Haskell type system and Programatica's type system in the process. Today I need to test my implementations to make sure there are no bugs. I also need to look for the "as a" contruct:

x@(Con1 x x) = ... x ...

Also I have been thinking about the talk Colin Runciman gave and also Haskell quick check. By my knowledge Haskell quick check uses a speciification that program must satisfy and then quick check tests that the properties hold in a large number of random test cases.

What would be better would be to use induction and proofs by equivelence.

Suppose we have an arbitrary function f...

f 0 = 1
f n = n * f (n-1)

Now, I want to prove that f will calculate the factorial of n. I can prove this by using induction. But what about creating a program that uses induction to prove the equality? This builds on Colin's talk - these arn't regular expressions, but its the same principle.

I think this will be really interesting to look into - however I realise that the work on refactoring takes top priority but I may give this some thought.

I was in the process of testing my refactoring today and I came to a few conclusions:

I still need to implement cases for parsing infix contructors and also constructors which use records.

Also w.r.t to naming identifiers on the LHS, I think it is a very difficult job. Not only will it be hard to work out the consistency (if there is any) oy naming for types - what happens in cases where the rcefactoring cannot infer a name? I think it is satisfactory to have an _ in place of a variable name, afterall the RHS simply calls a function which returns an error anyway so its not a huge problem.

The main reason I am thinking about this is because creating an algoritim to match naming consistencies is not an easy task. It will take time - and that time at the moment can be better spent on other things. Such as completing the refactoring etc...

Here is a list of things to do:
Implement functionality to deal with infiix expressions and records;
test refactoring and check into darcs;
get DrIFT working;
complete add constructor refactoring;
complete work on program slicing;
Continue reading Backhouse's book on program construction;
make a start on types and programming languages;

Also, Colin's talk yesterday has given me some inspiration for an idea. How about a program which uses induction to check whether a Haskell definition is correct or not? I thought it could be interesting. I know there is quickCheck, but I am not sure how it is implemented.

I have just made 2 new changes to my refactoring.

Now the user selects the constructor and the refactoring places the new constructor AFTER the selectded constructor. The refactoring places a space in between the new constructor and the "|" character.

Tonight I will add functionality to automatically create a function (that returns an error) and the new patterns will refer to that function.

Today I have set up a darcs repository for HaRe. This means you can use darcs to get the repository from the Internet:

darcs get http://www.cs.kent.ac.uk/projects/refactor-fp/release

I have also been making good progress on my refactoring, and I hope to be able to demo a promising start to Simon on monday. I have also had a think about pattern bindings:

Suppose we have a pattern binding:

(Con1) = 45

Then in my opinion, the refactoring cannot infer other pattern binding automatically - how does the refactoring know that it was the users intention to create pattern bindings for the new constructor. I think it is sensible to only check for patterns within function bindings and case expressions.

Claus made a good point today about trying to get a paper published, and I noticed this on the Haskell irc:

http://haskell.org/haskell-workshop/2006/

Perhaps I could try to publish a paper to that. Today I have also been updating the project website. I wanted to read another chapter of types and programming languages but setting up darcs took longer than I expected. I realised that the webpages directory is on a different server, so I couldn't just create a link to the repository - instead I have made a syncdarcs script which you run when you commit something, and the directories are synced.

After seeing a blog created by Malcome Wallace - I thought it would be a good idea to set up my own. After all - they seem to be the new fashion. This blog will be used as my own personal diary of my work - I will write down my thoughts, problems and progress about my PhD work here.