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 <[email protected]>
To: 'Pascal Jasmin' via Programming <[email protected]>
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 <[email protected]>
To: Programming forum <[email protected]>
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 <
[email protected]> 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
