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

Reply via email to