On Sunday, I wrote: During the week, I had been thinking about how I had become addicted to programming this interpreter; yesterday was certainly addiction, but it wasn't much fun. At the moment we're at the stage of clutching at straws with no fresh ideas of how to solve this problem that is down to memory management, something that Delphi - and expecially the very stable Delphi 7 version - is supposed to handle for the user.
Last night when I got into bed, I started thinking about the parser - not a recommended way of falling asleep, I note - when I had an epiphany. At some stage on Saturday, CoPilot had suggested saving the value that the parser was returning in a global variable or similar. This isn't a very good idea in terms of computer science and we ignored it. But last night, I realised that pointers to all the terms were being saved in the program's heap so that they could be disposed of during garbage collection. All I needed to do after parsing a clause in the rule's body was to walk down this heap, looking for the first (actually, the last) term of a specific type - this is the value that should be saved. CoPilot would never have 'thought' of this.
What does this mean in simple terms (pun not intended)? Let's say that there is the clause female (X). The parser will read the token female, and because of the bracket, it will know that this token is the functor of the clause. The token X will be then be read and a new term allocated (and stored on the heap) for this variable. Then a term will be allocated (and again, stored on the heap) for a compound item, consisting of the functor (female) and its arguments (X). So if I want to get the value of this term later on, it will found at the top (or close to the top) of the heap.
This solution, whilst quite brilliant, is sidestepping the actual problem that is preventing the proper execution of the code - but I'm prepared to accept the pragmatic solution if it keeps me moving forward. Incidentally, after using the value provided by walking the heap, the entire body was displayed correctly, which is a big step forward.
Next is checking that this rule can be resolved, just to ensure that everything is as it should be. Then will come the task of parsing a fact that has nested clauses such as owns (noam, cd (unhalfbricking, 'fairport convention')). I'm fairly sure that all I will have to do is change one statement in order to achieve this. I wonder whether the result of parsing these nested clauses will also display the same bug that I've just fixed (or at least, worked around).
But I'm going to beat my addiction and not touch this material for a few days.
Internal links
[1] 2037
| Title | Tags | ||
|---|---|---|---|
| 145 | Lonely at the top | MIDI, Randy Newman | |
| 305 | How to save money when ordering books from abroad | Book depository | |
| 306 | Alesis Q49 | MIDI, King Crimson, Antibes | |
| 521 | Warming up for DBA exam | DBA | |
| 777 | Enron's spreadsheets | DBA, Excel | |
| 1552 | Fairport news | Fairport Convention | |
| 1687 | The musical group reconvenes | Musical group | |
| 1862 | Shel Talmy, Peter Sinfield RIP | Obituary, King Crimson, Van der Graaf Generator |
No comments:
Post a Comment