Hi Raul,
I did mean exactly what I said in the statement:
"b) Through abandoning the right to left rule in tacit programming, J
`````finds it very difficult to identify which is intended."
_____________________________________________________
EXPLICIT J
In explicit J, a monadic verb takes an argument from its right,
transforms it and passes it to its left:
<-----------Monadic verb<---------------
So in a stream of monadic verbs, execution proceeds through each monadic
verb in turn:
<-- Monadic verb <-- Monadic verb <-- Monadic verb <--Monadic verb<--
However, a dyadic verb needs to receive an argument from its left as
well as from its right before passing the result to its left:
-----------> dyadic verb <------------
<-----------------------|
The entity to its left cannot be a verb, since no verb passes anything
to its right, so there has to be a noun or a noun phrase to its left:
Noun Phrase or
Verb Noun-------> dyadic verb <------------
<-----------------------------|
An example of a noun phrase would be: (t +7) or (%: p*2). The right to
left rule requires all noun phrases of this kind to be enclosed in
parentheses, so that they are executed before the result is passed to the
dyadic verb.
Thus an example of explicit J is:
MMMM 2*D MMM ND MMM (noun phrase)D MMMM
So the rule to identify whether a symbol is a dyadic verb or a monadic
verb is simple: every symbol is a monadic verb except when it has a noun or
a right parenthesis to its left.
THE FORK
The fork in explicit J is (M1y)DM2y . The verb D can be
identified as dyadic because it has a right parenthesis to its left.
M1 and M2 are without a noun or a right parenthesis to their left;
they are correctly identified as monadic.
_____________________________________________________________________________________
TACIT J
When moving the fork to tacit form, we need to remove the "y"s,
so that the fork consists of verbs. If the structure had
remained as it was, the fork in tacit programming
would have been: (M1)DM2 . The right to left rule would have
remained. The dyadic verb would still be identified by a right parenthesis
on its left. On execution, the right argument would be placed where
each of the "y"s had been.
However, for some benefit, which must have been good - but no one has
brought it up yet - the fork was changed to (M1DM2), which does not follow
the right to left rule. Supposing we have a stream of verbs in parenthesis,
say (%:+/+#^+:-), how do we know which is monadic and which is dyadic? There
is no noun or parentheses in the stream to help. We know that the first
three on the right are a fork, but what next? If it stops at 4, such as
(#^+:-), we know that the fourth is dyadic, because it becomes a hook.
In fact, the sequence is defined as alternating (DMDM) and that continues
indefinitely (MDMDMDMDMDM). Thus J tells whether a verb is monadic or
dyadic by its position in the stream. From the right, the odd numbered
positions are monadic and the even numbered positions dyadic.
Now the problem comes when we want to insert extra monadic verbs, say:
(MMDMDMMDM). The alternating sequence rule would get it wrong, So we
have to insert something between the first two "M"s from the right to say:
"The verb to my left is monadic, not dyadic": (MMDMDM@:MDM) Then
because the last verb will be assumed to be dyadic, we need a cap to
say: "This verb to my right is monadic, not dyadic". ([:MMDMDM@:MDM)
I don't know why there is a resistance in J to including constants in
the tacit stream, but there seems to be. Instead of plain: 3*MMM, J wants
3&*MMM, so we have another patch. This resistance also encourages us
to use "*:" instead of "2^~", "%:" instead of "0.5^~", +: and -:.
Thus a lot of patching is added in tacit programming due to the
inconsistency of abandoning the right to left rule. Had it remained, the
basic format of tacit programming would have been:
(M)D(M)D(M)D(M)DM , any number of extra monadic verbs could
have been added anywhere except on the left of the dyadic verbs:
MMM(MMM)DMMM(MMM)DMMM(MMM)DMMM and the dyadic verbs
would have been identified every time by a right parenthesis on their left.
___________________________________________________________
You say:
"You can not eliminate this treatment of ambivalence unless you
wish to exclude some very basic mathematical concepts or wish
to abandon classic mathematical notation.
I also wonder how - would be treated in a non-trivial phrase in
your hypothetical language. Would the language forbid the use
of - in such phrases? Or would the language only allow one
definition of - and not the other? Or would the language support
ambivalent expressions? Or would you introduce two words
for these two different concepts?"
Explicit J removes ambivalence by use of the right to left rule. I
would remove it in the equivalent of tacit programming by sticking with
the right to left rule. As a result, there would be no ambivalence anywhere.
As I described above, because tacit J abandons the right to left rule it has
to apply all sorts of patches to remove the ambivalence. I have not looked
at it carefully, but I am just noting that the documentation "Learning J",
which I have found very well written and helpful, says that in some cases J
has been unable to remove the ambivalence.
___________________________________________________________
Don
----- Original Message -----
From: "Raul Miller" <[email protected]>
To: "Chat forum" <[email protected]>
Sent: Friday, April 24, 2009 1:01 PM
Subject: Re: [Jchat] Language S
Before I begin here, I should mention that I do see a nice simplicity
in verb composition with purely monadic trains of verbs. I can also
see some attractions in extending this style of composition to include
dyadic verbs but I believe I can also see some potential problems with
this line of thought.
On Fri, Apr 24, 2009 at 11:51 AM, Don Watson <[email protected]> wrote:
> `````b) Through abandoning the right to left rule in tacit programming, J
> `````````finds it very difficult to identify which is intended.
This did not make any sense to me when I first read it. However, your
following statement:
> `````c) A variety of patches are needed to compensate, such as "@:",
> ````````"&" and "[:"
made your meaning clear to me. But I think (c) could stand on its
own (and be clearer) with very slight rephrasing. Perhaps: "J has
simple words, such as '@:', '&' and '[:' for its tacit expressions"
I should add, however, that most verbs are best understood in terms
of how they transform relevant data from within their domain. In the
case of a verb phrase, this would hold true for each of the component
verbs as well as for the phrase as a whole. I am quite certain that
changing the notation will do nothing to eliminate this issue.
In other words, I usually think in terms of the data in a "before/after"
sense, and usually do not use the dictionary definition of the word
or phrase, except as a tool for remembering how it transforms
data. I usually remember abstract terms (adverbs and conjunctions)
in terms of how they work with simple verbs such as < or [.
> `````d) In some cases, such as (f &: g) y and x (f &: g) y, Learning J
> says
> `````````the situation is still ambivalent.
Ambivalent is the word used to describe situations where
an operation has two distinct definitions, like:
OP y
x OP y
A classic example, of course, would be:
- 3
4 - 3
where the monadic and dyadic definitions for "-" are related but distinct.
You can not eliminate this treatment of ambivalence unless you
wish to exclude some very basic mathematical concepts or wish
to abandon classic mathematical notation.
I also wonder how - would be treated in a non-trivial phrase in
your hypothetical language. Would the language forbid the use
of - in such phrases? Or would the language only allow one
definition of - and not the other? Or would the language support
ambivalent expressions? Or would you introduce two words
for these two different concepts?
> `````e) J programmers tend to break mathematical formulae into small
> `````````subroutines to avoid the complexity - this loses the sense of
> `````````the mathematical formula, which is what the student is trying
> `````````to understand - a formula is like a map of the process.
I am having a problem seeing how (e) can be an accurate
statement.
When I am working on an algebra problem, I usually go through
a number of different (equivalent) expressions. Some will be long,
and complicated but my ultimate goal is to have an expression
which minimizes the complexity of my statement. I may also
use simple expressions and variable substitutions to make my
work easier.
I tend to follow a very similar process when working in J.
> `````e) I think that the tacit notation as it is has a big a learning
> `````````curve, and doesn't match existing mathematical notation well.
I typically have problems with expressing mathematical concepts
in J's notation when the text I am working with does not describe
the concepts adequately for me. In these cases, if I abandon J's
notation and attempt to follow along in a rote fashion, I can sometimes
eventually understand what is being described. Often, I can go back
and re-express the concepts using J and things will become clear to me.
There are exceptions of course, but they seem to be cases which
are not subject to calculations (either because I never understood
the concepts or because the concepts were not suitable).
Personally, I would favor expressing the same concept using different
notations (including english, of course) with good examples so
that if I have problems understanding one treatment I can move over
to a parallel treatment and try picking it up there. Parallel treatments
can slow down a presentation, so might not be suited for all situations,
such as review of existing concepts?
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
