THE PSACOMPILER EXPERIMENT ART Memo 10 (Version 0) Olaf Chitil, 2.8.2000 FREJA Freja warns about overlapping patterns and thus actually exposes one bug. 36 preliminary questions about CAFs were annoying. Most CAFs were definitely not related to the bug. Could skip CAFs by demanding to start with function main (implicitly answering yes to all questions about CAFs). However, obviously a CAF could be related to the bug, but we could not detect this any more. Parser values hard to read because of lambdas and too many local variables. But mostly: functions readable because: 1. names instead of lambdas used in program. (well chosen names even better) 2. values of local variables are shown. Find bugs in different order than in Hood or Redex Trail System. This is because order of questions is fixed. Sometimes a question is about an error one didn't yet want to tackle. However, answering questions incorrectly -- let's say this were correct -- is dangerous. In the beginning about 10 questions. Later sometimes about 30 questions. The less you know about a bug, the better is Freja. The more you know about a bug, the more akward is Freja. Sometimes same questions as in last debugging session. Could these and their answers be saved? In some questions I would really like to say directly which part of output is incorrect which would avoid the next questions. Note: It is not easy to follow why Freja asks certain questions and to understand how the source of the bug actually caused the visual bug. Automatically seeing the source would help. HOOD ghc warns about overlapping patterns and thus actually exposes one bug. Observed at up to 3 positions to locate a bug. Mostly observed function calls to see related arguments and results. Need to define instances of Observable for many data structures (easy but time consuming). Considerable modifications of the program: observe, putStrO, import Observe, instance Observable. In case of aborting program start observation close to point where error message is raised. The ghc error message "non-exhaustive patterns in function translateStatement" was sufficient to find a bug. Nhc and Freja do not name the function. Sometimes just looking at source (grep "Halt") is quickest way to locate bug. (Just searching a place for observe already reveals bug location; we use other systems without considering looking at source first; however, Redex Trail System is very quick in such a case as well). Higher-order functions are hard to read. Otherwise expressions are small and readable. Showing only demanded part keeps them small. Showing functions as demanded graph sometimes irritating (tableInsert 'x') but strengthens denotational view. REDEX TRAIL SYSTEM Looked at 0 - 6 parents to locate a bug. For "no pattern match" only used link to source. Additionally new missing pattern. Nearly always looked at parent of a subexpression; did not follow list of ancestors of one expression. Made use of looking up call in source extensively! Good that program uses named function instead of lambda abstraction for implementing table as function. Slightly irritating that local variables of function were not visible. All expressions where nicely small. Possible to locate several bugs in one session. (only danger that source of bugs turns out to be the same) Unexpected sharing of two expressions uncovered a bug. Bad that it is not possible to see which machine instructions belong together. The repeated application of ++ destroys the structure and leads to long trails until abstract program part could be reached.