A few notes here.
First, J does indeed use a stack in its parser. You mostly notice this
with adverb/conjunction composition (where the stack is used to
achieve "left to right" composition in a "right to left" parsing
environment).
But, second, you can easily use explicit stacks in J. The comma verb
can be used to put something on the stack and the {: or }: verbs can
be used to access the top of the stack or to drop something from it.
You can also use negative indexing with { for deeper access into the
stack. This will not be a forth implementation, but if that is what
you are looking for, you should probably start out with forth. But the
approach is valid and readily available.
Finally, the whole "no nouns in tacit code" is more of a definitional
issue than anything else. For some people, the presence of noun
references means that the code is not tacit. But tacit code always
lives in an environment which includes explicit code. This has several
consequences, which if spelled out would probably result in people
complaining more than anything else. That said, making a fork which
references a noun is trivial - but people who emphasize tacit code do
not like doing that.
Thanks,
--
Raul
On Wed, Aug 3, 2016 at 10:46 AM, Nicholas Spies <[email protected]> wrote:
> Hi Erling: (I hope this makes it to chat on the J forums-- please forward
> if only you get this)
>
> Your statement on your web page:
>
> "Another basic difference between explicit J and tacit J is that in tacit J
> there is no reference to the nouns. The nouns are still there, but there is
> nothing to denote them. It is like the persian language in which the vowels
> are never printed. The reader has to guess vowels until the resulting word
> makes sense in the context. In tacit J the reader has to construct the
> nouns in his mind. There are a lot of different functions for routing nouns
> to the right verb."
>
> I love J but have never comprehended tacit programming, with its hooks,
> forks and trains--which may lead to efficient interpreted code, but have
> always seemed to be to be a kluge to achieve extreme brevity. I would
> prefer tacit programming to explicit programming, because the latter seems
> too much like just another ALGOL-like language such as C, Pascal, etc. I
> like brevity, because, in coding, less is more--because shorter programs
> are far easier to comprehend and debug.
>
> My use of J has occurred in widely separated intervals, so I have had to
> relearn it multiple times and have never really mastered it. However, I
> never realized, per se, that tacit programming was just J abbreviated by
> making nouns implicit. Whether or not this results in spectacular speed
> increases, tacit J programs with their hooks, forks and trains are a devil
> to decipher. In my opinion, this is a needless price to pay to gain
> brevity.
>
> Now, this may sound completely crazy, but I would think that J would
> benefit tremendously if it were rewritten to use parameter stacks for nouns
> x and y, and explicit stack operators instead of a bunch of complicated
> rules to handle passing around 'invisible' parameters. Why do I think this?
> Because I co-authored a book with the late Mahlon Kelly "FORTH: A Text and
> Reference" Kelly and Spies, 1986, Prentice Hall. Forth was ridiculed by
> many for also having implicit values that were passed around on a parameter
> stack (and, optionally, even the return stack) to 'words' (short routines),
> each of which usually had requirements for something (one or more items)
> on the stack and optionally left something on the stack with finished and
> control passed to the next word, etc. This is expressed by a stack diagram
> ( x y -- z), which in some dialects (e.g. Factor) is used as a way of
> verifying that the stack effects of words was actually as stated.
>
> J doubtless uses the stacks for all sorts of things internally. Why not
> adopt explicit stack operators to manipulate implicit data, without
> sacrificing any of J's functionality. This would encourage a great deal
> more factoring of code into short, reusable functions, retaining brevity
> while increasing readability.
>
>
> On Wed, Aug 3, 2016 at 3:24 AM, Erling Hellenäs <[email protected]>
> wrote:
>
>> Yes.
>>
>> My article is about JWithATwist and the choice of syntax between the tacit
>> J syntax and a modified explicit J syntax.
>>
>> https://erlhelinfotech.wordpress.com/2016/08/01/jwithatwist-or-tacit-j/
>>
>> My example concerns the use of notation for communication. Maybe the word
>> "specification" was not well chosen.
>>
>> Anyway, good to know that APL can be compiled.
>>
>> /Erling
>>
>>
>> On 2016-08-02 15:52, Robert Bernecky wrote:
>>
>>> On 16-08-02 03:29 AM, Erling Hellenäs wrote:
>>>
>>>> I would for example like to be able to take the result of my analysis
>>>> and give to the C programmer as a specification.
>>>>
>>> You can already do that, if you write the analysis code in APL, and hand
>>> it to
>>> an APL compiler, of which there are several about. Writing a J front end
>>> for
>>> the APEX compiler would not be a huge effort; the remainder of the
>>> compiler
>>> would just work (modulo rational numbers and other J-only features, which
>>> could be added on an as-needed basis).
>>>
>>> Bob
>>>
>>>
>> ----------------------------------------------------------------------
>> 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
