From zoltan.somogyi at runbox.com Sat Apr 20 15:26:20 2019 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 20 Apr 2019 15:26:20 +1000 (AEST) Subject: [m-dev.] question about infinite recursion warnings Message-ID: Just before implementing Mantis 477 for Julien, I had a situation in which I could have used an infinite recursion warning but did not get one. It was a stock standard structural induction on a list, and as usual I copied-and-pasted the clause head to be the tail recursive call, but forgot to delete the list head, yielding code like this, which froze my machine for several minutes (before I could kill it) by running it out of memory: p([X | Xs], !S) :- ..., p([X | Xs], !S). This did not trigger the usual infinite recursion warning because some of the code inside the ... actually updated !S, so the second input arg was NOT unchanged between the clause head and the recursive call. I implemented a change that loosened the test for an infinite recursion warning. With this change, the compiler warns that calls like this, in which every input arg is *either* the same in the clause head and the call, *or* it is an instance of the same state variable in both places, will *probably* lead to infinite recursion. This diff generates this loosened form of the usual infinite recursion warning for my test case. However, it does not bootcheck, because it also generates warnings for some predicates in the standard library, which --halt-at-warn turns into errors. The predicates involved are gather_flag_chars in string.parse_util, and four different versions of simple_merge_renaming_loop in varset. After I got the warning for gather_flag_chars, in which all input args are state vars, I modified the heuristic to require at least one input arg not to be a state var, but the predicates in varset.m do have such input args. My question is: should I enable the new warning, either with or without this extra proviso, anyway? We could avoid the problem with --halt-at-warn by disabling infinite recursion warnings either module-wide (in Mercury.options), or just for the calls involved using the disable_warnings scope. The latter would require bootstrapping the change to the scope. Basically, my question boils down to: which is more annoying? Not getting an infinite recursion warning when you should, in situations resembling the one above, or getting one when you shouldn't? Zoltan. From novalazy at gmail.com Tue Apr 23 10:59:13 2019 From: novalazy at gmail.com (Peter Wang) Date: Tue, 23 Apr 2019 10:59:13 +1000 Subject: [m-dev.] question about infinite recursion warnings In-Reply-To: References: Message-ID: <20190423105913.GD1678@kola.localdomain> On Sat, 20 Apr 2019 15:26:20 +1000 (AEST), "Zoltan Somogyi" wrote: > Just before implementing Mantis 477 for Julien, I had a situation > in which I could have used an infinite recursion warning but > did not get one. It was a stock standard structural induction > on a list, and as usual I copied-and-pasted the clause head > to be the tail recursive call, but forgot to delete the list head, > yielding code like this, which froze my machine for several > minutes (before I could kill it) by running it out of memory: > > p([X | Xs], !S) :- > ..., > p([X | Xs], !S). On Linux, press Alt+SysRq+F to invoke the OOM killer (assuming Magic SysRq is enabled). > > Basically, my question boils down to: which is more annoying? > Not getting an infinite recursion warning when you should, > in situations resembling the one above, or getting one when > you shouldn't? Without having tried it, probably getting wrong warnings would be more annoying. Perhaps such warnings should be opt-in, then the user cannot complain about false positives. Peter From jfischer at opturion.com Tue Apr 23 11:26:01 2019 From: jfischer at opturion.com (Julien Fischer) Date: Tue, 23 Apr 2019 01:26:01 +0000 (UTC) Subject: [m-dev.] question about infinite recursion warnings In-Reply-To: References: Message-ID: On Sat, 20 Apr 2019, Zoltan Somogyi wrote: > My question is: should I enable the new warning, either with > or without this extra proviso, anyway? We could avoid the problem > with --halt-at-warn by disabling infinite recursion warnings > either module-wide (in Mercury.options), or just for the calls > involved using the disable_warnings scope. The latter would > require bootstrapping the change to the scope. > > Basically, my question boils down to: which is more annoying? > Not getting an infinite recursion warning when you should, > in situations resembling the one above, or getting one when > you shouldn't? I agree with Peter here, warning about probable (as opposed to definite) infinite recursion should be opt-in by default, so you should add a new option that controls whether the extra heuristics are enabled. (I have no objection to enabling the new option for the Mercury system itself.) Julien. From zoltan.somogyi at runbox.com Wed Apr 24 07:55:17 2019 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Wed, 24 Apr 2019 07:55:17 +1000 (AEST) Subject: [m-dev.] question about infinite recursion warnings In-Reply-To: References: Message-ID: On Tue, 23 Apr 2019 01:26:01 +0000 (UTC), Julien Fischer wrote: > > > On Sat, 20 Apr 2019, Zoltan Somogyi wrote: > > > My question is: should I enable the new warning, either with > > or without this extra proviso, anyway? We could avoid the problem > > with --halt-at-warn by disabling infinite recursion warnings > > either module-wide (in Mercury.options), or just for the calls > > involved using the disable_warnings scope. The latter would > > require bootstrapping the change to the scope. > > > > Basically, my question boils down to: which is more annoying? > > Not getting an infinite recursion warning when you should, > > in situations resembling the one above, or getting one when > > you shouldn't? > > I agree with Peter here, warning about probable (as opposed to definite) > infinite recursion should be opt-in by default, so you should add a > new option that controls whether the extra heuristics are enabled. > (I have no objection to enabling the new option for the Mercury system > itself.) The attached diff adds the proposed new option. I welcome opinions about its name. The rest of the diff is boring. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.ir Type: application/octet-stream Size: 1176 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.ir Type: application/octet-stream Size: 14563 bytes Desc: not available URL: From novalazy at gmail.com Wed Apr 24 10:41:29 2019 From: novalazy at gmail.com (Peter Wang) Date: Wed, 24 Apr 2019 10:41:29 +1000 Subject: [m-dev.] question about infinite recursion warnings In-Reply-To: References: Message-ID: <20190424104129.GC1258@kola.localdomain> On Wed, 24 Apr 2019 07:55:17 +1000 (AEST), "Zoltan Somogyi" wrote: > > The attached diff adds the proposed new option. I welcome opinions > about its name. The rest of the diff is boring. How about a generic name like --warn-suspicious-recursion? Peter From zoltan.somogyi at runbox.com Wed Apr 24 10:46:57 2019 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Wed, 24 Apr 2019 10:46:57 +1000 (AEST) Subject: [m-dev.] question about infinite recursion warnings In-Reply-To: <20190424104129.GC1258@kola.localdomain> References: <20190424104129.GC1258@kola.localdomain> Message-ID: On Wed, 24 Apr 2019 10:41:29 +1000, Peter Wang wrote: > On Wed, 24 Apr 2019 07:55:17 +1000 (AEST), "Zoltan Somogyi" wrote: > > > > The attached diff adds the proposed new option. I welcome opinions > > about its name. The rest of the diff is boring. > > How about a generic name like --warn-suspicious-recursion? To my mind, that is more generic than what we discussed and I intend to implement. How about --warn-suspicious-infinite-recursion? Zoltan. From novalazy at gmail.com Wed Apr 24 11:15:44 2019 From: novalazy at gmail.com (Peter Wang) Date: Wed, 24 Apr 2019 11:15:44 +1000 Subject: [m-dev.] question about infinite recursion warnings In-Reply-To: References: <20190424104129.GC1258@kola.localdomain> Message-ID: <20190424111544.GH1258@kola.localdomain> On Wed, 24 Apr 2019 10:46:57 +1000 (AEST), "Zoltan Somogyi" wrote: > > > On Wed, 24 Apr 2019 10:41:29 +1000, Peter Wang wrote: > > > On Wed, 24 Apr 2019 07:55:17 +1000 (AEST), "Zoltan Somogyi" wrote: > > > > > > The attached diff adds the proposed new option. I welcome opinions > > > about its name. The rest of the diff is boring. > > > > How about a generic name like --warn-suspicious-recursion? > > To my mind, that is more generic than what we discussed and I intend > to implement. > > How about --warn-suspicious-infinite-recursion? Sure, I almost suggested that anyway. I do think the shorter name is fine, though (and preferable for being shorter). Peter From mikeday at yeslogic.com Wed Apr 24 11:16:22 2019 From: mikeday at yeslogic.com (Michael Day) Date: Wed, 24 Apr 2019 11:16:22 +1000 Subject: [m-dev.] question about infinite recursion warnings In-Reply-To: References: <20190424104129.GC1258@kola.localdomain> Message-ID: > How about --warn-suspicious-infinite-recursion? Implies the existence of suspicious non-infinite recursion, or possibly non-suspicious infinite recursion :) Michael -- Prince: Print with CSS! http://www.princexml.com From zoltan.somogyi at runbox.com Wed Apr 24 11:31:20 2019 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Wed, 24 Apr 2019 11:31:20 +1000 (AEST) Subject: [m-dev.] question about infinite recursion warnings In-Reply-To: References: <20190424104129.GC1258@kola.localdomain> Message-ID: On Wed, 24 Apr 2019 11:16:22 +1000, Michael Day wrote: > > How about --warn-suspicious-infinite-recursion? > > Implies the existence of suspicious non-infinite recursion, or possibly > non-suspicious infinite recursion :) Good point, but the first actually exists, and maybe the second does as well. For suspicious non-infinite recursion, consider this: p([X | Xs], A0, B0, Out) :- update_a(X, A0, A1), update_b(X, B0, B1), p(Xs, B1, A1, Out). The suspicion comes from the swapping of the A and B args; nothing to do with infinite loops. As for the second, in realtime systems and operating systems, infinite recursion is the *intended* behavior (in the absence of an explicit shutdown command, that is). The correctness proofs of such systems require a proof of *non*-termination. Whether such intended infinite recursive calls could be called suspicious is in the eye of the beholder. Zoltan.