Tools in the toolbox
November 11, 2009by Nathan Whitehouse (nw08)
The key to this project is figuring out the best bits of code to give the machine. What tools does it need to produce a program? The first step was breaking down what the application should be able to do; each of these functions requires a test. To test an address book, for example, we may want to:
Display all entries
Add a new entry
Search by name
Edit the entry found by the search
Display entries again
Do an incomplete search (‘step’ for stephen)
Delete an entry.
So for each thing I planned on asking the program to do, I tried to write out what steps the program would need to take. This was something that got much easier once I started doing it on paper, instead of starting off with code. The first time I would write one of these out, it would be mostly questions. I knew, naturally, that ‘create a new list’ would be a function involved in creating a new entry, but immediately after were questions such as ‘what ‘state’ does the program have to be in?’ and ‘do we need a global ‘activeList’ variable for editing?’. After that I thought, and tried to write out the basic tools.
This approach did help clear some of my understanding of what this program needs to do, but once I started trying to transfer some of it into code, I realized that it wasn’t enough. I also needed to know exactly how our back-end system was going to work.
Once again, the idea is that the GUI, and the stuff that would be tedious and redundant to evolve, such as reading keypresses correctly, would be handled by a human-coded backend ‘interpreter’ of sorts. With Schush/Push and an evolved program, it is not immediately intuitive how to integrate such a system. The code Schush produces is, by and large, a mess to human eyes, and can’t be run on it’s own. It’s pretty much impossible to manually add elements into the scheme program, such as input prompts, where you might want them.
My current thinking (and this is something I plan to talk to Lee about in depth soon) is that the program I evolve and the backend should both depend highly on an external state variable. If that state is set to ‘edit’ at the time the program is called, for example, it will do something completely different when it is run than it would if that state was set to, say search. So, if we wanted to create a new list, it might go something like this.
Program is in a ‘neutral’ state (this would probably just translate to displaying all entries)
If the ‘new list’ button is pressed, the program is called, and changes itself to ‘entry’ state, then terminates.
The backend behaves differently because the state is set to ‘entry’. It now prompts the user for input. When the user is finished with this input, it is saved to temporary storage, and the schush program is called again.
Because the program state is now ‘entry’, the schush program behaves differently. It now grabs the list from temporary storage, and puts it into the master list, and sets itself back to the ‘neutral’ state before terminating.
In the case of entering a list, then, a successful schush program would have to do very little. It would have to be able to change its state to entry if it is in the default state, and if it is in the other state, all it has to do is put grab an external list, then put it into the master list, then change its state one more time. So in terms of that functionality, evolution by this approach is saving us very little time. On a more complicated function such as a search function, however, that should change. The backend still does about the same amount of work – accept user input, then pass it on – but the program has to do much more.
The ‘new entry’ program is making progress. There is a problem in my error function which didn’t punish it for not going back to the default state afterwards. It is very short, but it still is able to create a new list.
Here it is: (consAux intoEdit newListSafer)
These are all functions I have defined. Because there are only two states, it does not need any sort of conditionals or other mumbo jumbo. It can just cycle through states. This will certainly have to change in future versions.