I glad to hear that and, as I said, I hope you can make some progress on
the stack problem. I wonder how other powerful interpreters such as
Python, Haskell, K (or Kona, its open source clone), etc. deal (or also
fail to deal?) with this kind of problem. Even if it turns out to be an
unavoidable problem associated with the structure of the J language,
personally, it would be a price which I certainly continue to pay.
By the way, thanks for the elaboration regarding crashing versus hanging
(it makes sense).
On Wed, May 18, 2016 at 5:04 PM, Henry Rich <henryhr...@gmail.com> wrote:
> I am proposing to call that a domain error.
>
> I think you have the better arguments, so I withdraw my proposal.
>
> Henry Rich
>
>
> On 5/18/2016 4:35 PM, Jose Mario Quintana wrote:
>
>> The fact that there are gerund recursions that crash the interpreter does
>> not imply that all of them do so. Your "solution," as I understand it,
>> would report a "stack error" for the following recursive sentence which,
>> as
>> far as I can see, follows the current Dictionary rules and causes no harm
>> at all,
>>
>> ([`([`1:@.(0 >: ([ echo f.)@:]))`(1 -~ ]))&('no stack error'"_^:[) 7
>> 7
>> 6
>> 5
>> 4
>> 3
>> 2
>> 1
>> 0
>> no stack error
>>
>> Is that correct?
>>
>> The above sentence is just a proof of concept, but I see the potential for
>> tacit anonymous recursions, capable of modifying is own code dynamically,
>> and linked to an ending, more typical, verb power construction... Wow! I
>> have used other means to achieve the same (minus the built-in link to the
>> verb power construction) but this form looks slick! Maybe that is what
>> Dan
>> had in mind because a self-replicating form is usually the simplest proof
>> of concept.
>>
>> Incidentally, if you are asking for a monadic verb (isgerund) that
>> produces
>> 1 if (and only if) its argument is a gerund then it would be hard to
>> improve upon the one in [0] (mind you, a trouble-maker can trick it).
>>
>> All this reminds me of an actual incident while I was taking a class in
>> high school: a guy in the front asked permission to go to the infirmary
>> complaining about a terrible headache and immediately another guy in the
>> back suggested "they should cut his head off;" one went to the infirmary,
>> the other one to detention. I do not know for sure who went to which
>> place
>> ;)
>>
>>
>> [0] [Jprogramming] how to test for a gerund
>>
>> http://www.jsoftware.com/pipermail/programming/2010-April/019178.html
>>
>>
>> On Tue, May 17, 2016 at 3:21 PM, 'Pascal Jasmin' via Source <
>> sou...@jsoftware.com> wrote:
>>
>> mentioned this before but,
>>>
>>> the best solution to me is:
>>>
>>> u^:(v0`v1`v2) NB. or any gerund variation modification to v1
>>>
>>> would be interpreted as
>>>
>>> u^:(v0`((][ 'stack error' assert -.@isgerund)@:v1)`v2
>>>
>>>
>>>
>>> This solves the gerund recursion problem without prohibiting ^:v to
>>> create
>>> initial gerund.
>>>
>>> I remember asking but not finding a searchable response to creating a
>>> universal isgerund function, but for this case,
>>>
>>> notgerund =: ((1 = #)+. 0 = L.)
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: Henry Rich <henryhr...@gmail.com>
>>> To: sou...@jsoftware.com
>>> Sent: Tuesday, May 17, 2016 1:01 AM
>>> Subject: Re: [Jsource] In u^:v, v may not return a gerund (proposal)
>>>
>>> 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 <cbu...@jsoftware.com>
>>>>
>>> wrote:
>>>
>>>> ---------- Forwarded message ----------
>>>>> From: Henry Rich <henryhr...@gmail.com>
>>>>> Date: 8 May 2016 at 12:17
>>>>> Subject: In u^:v, v may not return a gerund (proposal)
>>>>> To: jeng...@jsoftware.com
>>>>>
>>>>>
>>>>> 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
>>
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
