Following is a demo of the Blocks World Task Three program.
?- plan([on(b1, table), on(b2, table), on(b3, table), on(b4, table), on(b5, table),on(b6, table), on(b7, table), on(b8, table)],
[on(b1, table), on(b2, b3), on(b3, b1), on(b4, b5), on(b5, b6),on(b6, table), on(b7, b4), on(b8, b7)]).
The result...
the large yellow block is on the table
the large red block is on the large blue block
the large blue block is on the large yellow block
the large green block is on the small yellow block
the small yellow block is on the small red block
the small red block is on the table
the small blue block is on the large green block
the small green block is on the small blue block
true .
For this task I started with the idea of stacking from the table up. Using this thought process, there's no need to use the clear function because we are never attempting to pick up a block that is not initially on the table (assuming the initial state is all blocks sitting on the table). Because blocks that remain on the table in the goal state don't need to be stacked, I started by making a list of those blocks (because every other block will build off of those directly on the table). This is accomplished by findBases.
Once those on the table are established, I needed to work level by level to reach the highest block(s) using recursion. With the blocks on the table as the first level, nextStackLevel uses the goal state to find any blocks that stack on the current level of blocks. When it does, it performs the stack maneuver and adds said block to a list of blocks on the next level. It finishes recursing once it's found any and all blocks stacked on the current level of blocks. It's then the job of executePlan to recurse through each level of blocks until the current state equals the goal state.
I wasn't sure how well this task would go for me, but I had high hopes because I enjoyed the first two tasks and doing the extra credit. I found my biggest difficulty not in the heuristic, but in Prolog's lack of scope, resulting in my big long nextStackLevel rule to save variables from being lost during recursion (thanks to 344's project, I had seen this problem before, but adding yet another variable to the list pained me). My biggest issue was when a block had nothing on top of it and member(...) would fail, but I needed execution to continue, which I circumvented with the executeBlock rule. The rest of my debugging fell into making sure variables were properly updated and the newest versions were passed on.
I added small annotations to the code itself, but I wanted to type my thought process up because I really enjoyed working on this task once I got into the flow of it (and didn't notice how many hours passed). I'm curious what you think of it.