Right, the first two sentences I mentioned do not crash the interpreter although the first one hangs it; the last one crashes the interpreter.
The sentence ($: $: $:)_ runs indefinitely and apparently pumping the J brake does not stop it; in contrast, for instance, $:_ |stack error | $:_ reports a meaningful error. The sentence (>:^:6666666666666666666666666666666666666666x)0 also runs indefinitely but pumping the J brake stops it; yet a seemingly minor change apparently makes it unstoppable (when pumping the J brake), ( ]^:6666666666666666666666666666666666666666x)0 Your comment seems to imply that crashing is a lot more alarming than hanging. If that is case, can you elaborate why? At any rate, the sentence ]`]}]`] crashes the interpreter and as you pointed out other sentences do so as well. Thus, I wonder, why should one be so concerned about this particular type of obscure sentences that push the interpreter too far and induce a crash? How long would have taken for the rest of us to realize about this specific "problem" if Dan had not reported it? Who knows how many are there hiding somewhere? I remember at least a couple of my own making. I do not know exactly what you mean by "actual code" because, in my mind, the references that I provided show actual code. Be that as it may, I would rather go the other way around: if the problem is not preventing the production of "actual code" then I would not legislate out anything. Why? Because, as a matter of principle, I would like for J to do more rather than less and I dislike regulations that interfere with my freedom to do whatever I might want to do. Besides, it seems to me that, the "solution" is only cosmetic and just for a very specific kind of sentences and it does practically nothing for solving the real issue. Instead, I hope that Raul and you and others succeed in eradicating the "root of the problem." On Tue, May 17, 2016 at 1:01 AM, Henry Rich <[email protected]> wrote: > The root of the problem is that 'stack error' is unreliable. Depending on > how much execution stack each recursion uses, you may get a J crash rather > than a stack error. I am thinking about ways to fix this, but I haven't > found one yet. The simple cases you give do not crash, but if you throw in > " and ^: a few times in the recursive part, they will crash. > > In the meantime, an alternative is to prevent sources of stack error, and > this one could be pretty easily fixed by legislating it out of existence. > > My guess also is that the sentence was not an accident, and that Dan Bron > was noodling around on the fringes when he found it. If no one has ever > used verb-producing-gerund to solve an actual problem, that to me would be > license enough to put it to the sword. > > I would like to leave it that if I can't find a bulletproof fix for the > stack error problem, we will remove this source of error from ^: (and also > from }, as you mention), UNLESS someone can show cause why the current > behavior should be retained. I will take no action without a consensus > from the J community (and I don't have authority to do so anyway). > > Henry Rich > > > > On 5/15/2016 12:35 PM, Jose Mario Quintana wrote: > >> That sentence is very interesting. How did originate? My guess is that >> it >> was not an accident. >> >> Rather than a problem I see a potential opportunity; it is a tacit >> construction and, usually, variants of self-replicating forms can be quite >> useful. The sentence f^:] 0&]`] is akin to the sentence $: 0 ; one >> should be careful about what one is asking the interpreter to accomplish. >> In my opinion, the users should be, and ultimately are, responsible for >> their actions. There are many other trouble making sentences, >> >> ($: $: $:)_ >> (>:^:6666666666666666666666666666666666666666x)0 >> ]`]}]`] >> >> etc. >> >> Why one should be focusing on this f^:] 0&]`] (and other similar >> sentences >> involving ^:) in particular? The easiest fix seems too drastic, to me at >> least, since it would imply changing not just the Dictionary entry for ^: >> (incidentally, in that entry } is referred as the "merge" adverb, which is >> news to me) but arguably also for } since the sentence ]`]}]`] also >> crashes the interpreter in a similar fashion. >> >> For an example where creating a gerund makes sense see [0]; not to mention >> [1]. >> >> For what is worth, clearly, I do not like this proposal: it would require >> changes to the dictionary; these changes would add complexity to the >> definitions; the definitions would be less consistent since they would >> introduce exceptions. Although the change would prevent certain crashes, >> which are unlikely to occur by chance, it would do so by forcing a >> limitation which might even brake some existent code. >> >> PS. After years of neglect, I am glad to see a lot of activity around the >> J Engine. I am particularly interested to experience the results of the >> Reference count update status project. >> >> References >> >> [0] [Jprogramming] conjunction in tacit verb >> >> http://www.jsoftware.com/pipermail/programming/2015-February/040994.html >> >> >> [1] [Jprogramming] applying >1 gerunds to a set of items >> >> http://www.jsoftware.com/pipermail/programming/2013-January/031234.html >> >> >> On Wed, May 11, 2016 at 10:02 PM, chris burke <[email protected]> >> wrote: >> >> ---------- Forwarded message ---------- >>> From: Henry Rich <[email protected]> >>> Date: 8 May 2016 at 12:17 >>> Subject: In u^:v, v may not return a gerund (proposal) >>> To: [email protected] >>> >>> >>> I am working on an old problem: >>> >>> f^:] 0&]`] >>> >>> crashes, because executing ] creates a gerund, which executes to produce >>> the same gerund, etc. >>> >>> The easiest fix is to decree that in u^:v, ([x]v y) may not produce a >>> gerund. Similarly in the forms u^:[v0]`v1`v2, ([x] v1 y) may not >>> produce a >>> gerund. >>> >>> Anybody got a problem with that? I can't think of any case where >>> creating >>> a gerund makes any sense at all. >>> >>> Henry >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm >>> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
