[Jprogramming] threaded code

[Henry Rich]

That's not wrong, except that J is interpreted, with the surprises that 
go along with that.

But it misses the essential genius of J, which is the rank concept 
combined with modifiers. Verb tokens don't stand in for calls to C code: 
they stand for computational elements, which are combined by modifiers.  
Describing / monad as a compiled subroutine gives the Gentile (Jentile?) 
a too-simple idea of what it does.

Henry Rich

On 1/25/2016 11:18 PM, 'Pascal Jasmin' via Programming wrote:
> My thought was that J's primitives were compiled subroutines, and so it fit within the concept of the leading sentence description.  I agree that its hard to see the relevance of any of the detailed descriptions though.
>
>
> I described J as an interpreted language that needs few type checks (homogeneous arrays), and where tokens are standins for calls to C code.  I was told I just described threaded code.
>
>
>
> ----- Original Message -----
> From: bill lam <bbill.lam at gmail.com>
> To: 'Pascal Jasmin' via Programming <programming at jsoftware.com>
> Sent: Monday, January 25, 2016 10:41 PM
> Subject: Re: [Jprogramming] threaded code
>
> I suspect threaded code had become irrelevant many years ago.
>
>
> Вт, 26 янв 2016, jprogramming написал(а):
>> I made the same assumption as you when first hearing the concept of threaded code.  If you read the link, it has nothing (or little) to do with single vs multi threaded code.
>>
>>
>>
>>
>> ----- Original Message -----
>> From: Raul Miller <rauldmiller at gmail.com>
>> To: Programming forum <programming at jsoftware.com>
>> Sent: Monday, January 25, 2016 10:12 PM
>> Subject: Re: [Jprogramming] threaded code
>>
>> Yes - mostly (but not entirely) as something to be avoided.
>>
>> You can emulate threading with gerunds, if you are also willing to maintain
>> a stack. J's implementation also has contained some overhead from threaded
>> attempts which wound up causing more problems than they solved. But mostly
>> threaded code winds up being a lot of wasted motion, in the context of the
>> kind of program which J is well suited for.
>>
>> Threaded code can be nice, however, for fast animated contexts, such as
>> games. J is suitable for tools to edit data structures used in games, and
>> it's suitable for exploring concepts useful in games, but I think you'll
>> need to refactor a threaded game architecture before using J to implement
>> it.
>>
>> That said, threading can also be nice for servicing user interface
>> mechanisms. If jqt had a way of interrupting a J program, the interrupt
>> servicing code would need to be an independent thread.
>>
>> Thanks,
>>
>> -- 
>> Raul
>>
>> *
>>
>>
>> On Mon, Jan 25, 2016 at 8:54 PM, 'Pascal Jasmin' via Programming <
>> programming at jsoftware.com> wrote:
>>
>>> https://en.wikipedia.org/wiki/Threaded_code
>>>
>>> Does this concept apply to J's implementation in any way?
>>> ----------------------------------------------------------------------
>>> 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