Dear all, sometimes, the compiler leaves spurious choice points, i.e., choice points that are later discovered to be not there. I thought (or hoped) that these "false" choice points would be eliminated by optimization via type testing. Is there any way to prevent this? It is somewhat distracting during tracing and bug fixing. Best regards, Ulrich An example: --- ttt.ecl --- t2(T1, _T2) :- free(T1), !, writeln(a). t2(_T1, T2) :- T2 \== [], writeln(b). t2(_T1, []) :- writeln(c). ---------------- scholz_at_...290...:~/Forschung/Invarianten/Version_2010_12_09$ eclipse ECLiPSe Constraint Logic Programming System [kernel] Kernel and basic libraries copyright Cisco Systems, Inc. and subject to the Cisco-style Mozilla Public Licence 1.1 (see legal/cmpl.txt or www.eclipse-clp.org/licence) Source available at www.sourceforge.org/projects/eclipse-clp GMP library copyright Free Software Foundation, see legal/lgpl.txt For other libraries see their individual copyright notices Version 6.0 #154 (i386_linux), Fri Jul 16 06:11 2010 [eclipse 4]: [ttt]. source_processor.eco loaded in 0.00 seconds hash.eco loaded in 0.01 seconds compiler_common.eco loaded in 0.02 seconds compiler_normalise.eco loaded in 0.00 seconds compiler_map.eco loaded in 0.00 seconds compiler_analysis.eco loaded in 0.00 seconds compiler_peephole.eco loaded in 0.01 seconds compiler_codegen.eco loaded in 0.01 seconds compiler_varclass.eco loaded in 0.00 seconds compiler_indexing.eco loaded in 0.01 seconds compiler_regassign.eco loaded in 0.01 seconds asm.eco loaded in 0.01 seconds module_options.eco loaded in 0.00 seconds ecl_compiler.eco loaded in 0.08 seconds ttt.ecl compiled 412 bytes in 0.00 seconds Yes (0.08s cpu) [eclipse 5]: t2(y,z). b Yes (0.00s cpu, solution 1, maybe more) ? ; No (0.00s cpu) [eclipse 6]:Received on Wed Jan 19 2011 - 15:23:26 CET
This archive was generated by hypermail 2.3.0 : Wed Sep 25 2024 - 15:13:20 CEST