Path: utzoo!attcan!uunet!mcvax!unido!ecrcvax!micha From: micha@ecrcvax.UUCP (Micha Meier) Newsgroups: comp.lang.prolog Subject: Re: The double-cut (The Four-Port Debugger) Message-ID: <609@ecrcvax.UUCP> Date: 8 Aug 88 08:43:47 GMT References: <1162@ttds.UUCP> <208500002@s.cs.uiuc.edu> <227@quintus.UUCP> Reply-To: micha@ecrcvax.UUCP (Micha Meier) Organization: ECRC, Munich 81, West Germany Lines: 35 In article <227@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >"Four-port" debuggers are _supposed_ to show "redo"s of built-in predicates. >... >Would it be clearer if the "redo" port were renamed to "Next" (short for >"please give me your next solution"? (C Prolog actually calls this >port "Back", I think, because the debugger isn't _quite_ a four-port one.) I think it would be interesting if people would report about their experiences with real four-port debuggers - is it really necessary to show REDO of deterministic calls? I always get lost when the system backtracks a lot, usually the important information disappears from the screen. Normally, I know which call is the most recent one that has a choice point and it is tiring to get redo's I'm not interested in. I suggest that the REDO ports correspond only to calls with a choice-point left, deterministic calls would only have two ports, CALL and EXIT. By showing only the call with an active choice-point it is clear that all the calls inbetween have failed and they cannot be resatisified. The only objection I can see is that one might not know where exactly is the REDO port that eventually exits, when all the parent calls are not shown. The solution is simple, however - just look at the ancestors of the given call (using the debugger option). This actually means that if there is potentially a lot of data to be shown, it is shown only on demand, not by default. Such a scheme is simpler both for the user and for the implementor (especially for tracing compiled code). (Btw, are there Prologs around which can trace compiled code? We'd like to share some experiences on this topic.) --Micha