And of course, you are right - I read the title and skimmed a few
paragraphs and came up with some ideas but didn't bother working
through the details enough to see that I was going down the wrong
path. (Which reminds me: people who complain about J being hard to
read probably haven't thought enough about the difficulties of using
English.)
And, like Henry pointed out, this "threaded code" concept is really
about forth implementations (and forth-like implementations).
For an example of some of the difficulties you'd have with J, if you
tried to implement J this way, consider these two simple examples:
(A) Form a sequence of gerunds of verbs, use `:6 to transform them
into a train, then use a 5!:x expression to display that verb.
(B) Use the verb in a monadic context and then in a dyadic context.
(C) Find the rank of that verb (this was an example Henry's used)
To make this more concrete
Displaying a verb:
+/`%`#`:6
+/ % #
Using its monadic definition:
+/`%`#`:6] 2 3 5 7
4.25
Using its dyadic definition:
1 1 1 1 +/`%`#`:6] 2 3 5 7
1.5 2 3 4
1 1.33333 2 2.66667
0.6 0.8 1.2 1.6
0.428571 0.571429 0.857143 1.14286
Finding its rank:
+/`%`#`:6 b. 0
_ _ _
Note also that some verbs can be constructed to have identity values
and obverses.
Anyways, implementing this using "threaded code" would add some
overhead (and would be doable) but it's probably not really the right
data structure to be using. What we have is closer to a "purely
functional object oriented" system, but that's not going to be an
exact fit, either.
That said, I imagine that re-implementing J in forth (and/or in
haskell) would definitely be possible and would also teach you a lot
about both (or each) of the languages.
Thanks,
--
Raul
On Mon, Jan 25, 2016 at 10:32 PM, 'Pascal Jasmin' via Programming
<[email protected]> wrote:
> 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
