Crashing is worse than a stack error because you may lose session data,
and it is harder to find out which sentence caused the crash.
One other argument for suppressing unused exotic forms is that dissect
can't handle them. Not a great argument, I admit.
Henry Rich
On 5/18/2016 3:30 PM, Jose Mario Quintana wrote:
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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
