On Fri, Apr 24, 2009 at 9:02 PM, Don Watson <[email protected]> wrote: > 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."
To my knowledge J, the language, does not experience efforts -- I believe that is something only humans can do. > EXPLICIT J > > In explicit J, a monadic verb takes an argument from its right, > transforms it and passes it to its left: I would express this differently: In an explicit sentence, when a monadic verb is combined with a noun, the pair of them are replaced by their result. However, except in the context of parenthesis, I believe the consumer of this result must be on the left. This is because the parsing rule for monadic verbs is very low priority and by the time we get around to evaluating a monadic verb there is not much of anything else left to do. > 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: For example, 1 + 1 This is not a contrivance of J, but a fundamental characteristic of standard mathematical notation. > 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: Put differently, if there was not a noun to its left, the dyadic verb rule could not take effect. But when there is a noun to its left we can use the dyadic verb parsing rule. For example: conj=: 2 :'3' + conj - * 7 Here, the entity to the left of the asterisk is a hyphen, which represents a verb. However the conjunction parsing rule kicks in before any verb parsing rules, and the above sentence is equivalent to 3 * 7 > Noun Phrase or > Verb Noun-------> dyadic verb <------------ > <-----------------------------| > > An example of a noun phrase would be: (t +7) or (%: p*2). This, of course depends on the values of t and p. However, if this is not a noun phrase it can only be a syntax error. So I agree with you. > 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. When they are used as the left argument to a dyadic verb, this is true. When they are used as the right argument to a dyadic verb, this is false. (for example) > Thus an example of explicit J is: > > MMMM 2*D MMM ND MMM (noun phrase)D MMMM I do not understand this sentence, but this does not look like explicit J for any likely meanings of these names. Note, in particular, that your rightmost word seems to be a monadic verb. > 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. ...unless it is something else? For example, consider / in +/1 2 3. > 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. Forks are tacit, not explicit. Names in J must be separated by spaces. You perhaps meant to say that the fork (M1 D M2) y is equivalent to the explicit expression (M1 y) D M2 y? > When moving the fork to tacit form, we need to remove the "y"s, If you are speaking only of the explicit expression (M1 y) D M2 y, then this is accurate. > 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. This right to left rule seems somewhat contrived. (M1 D M2) y is equivalent to (M1 y) D M2 y Some things are happening here besides a simple left to right movement of data. In particular, the y value is cloned. And then, after that, the result of M1 y could be said to be "moving to the right" into D. > However, for some benefit, which must have been good - but no one has > brought it up yet - I believe expressions such as f + g are fairly common in some branches of mathematics (differential equations comes to mind, but they are not the only examples). > the fork was changed to (M1DM2), which does not follow > the right to left rule. Dyadic verbs do not follow any right to left rule. In the expression 1 + 2, the number one "moves from the left to the right" into the addition operation. > Supposing we have a stream of verbs in parenthesis, > say (%:+/+#^+:-), how do we know which is monadic and which is dyadic? If I had to answer this question, I could type the expression into J, and J tells me that +/ and # and +: must be dyadic verbs because they combine results from the other verbs. > 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. (3 * i.) 4 0 3 6 9 > Thus a lot of patching is added in tacit programming due to the > inconsistency of abandoning the right to left rule. Well... I do not think of this as patching, nor do I think of this as inconsistency, and I do not think the "right to left rule" is a valid rule, but other than that I agree with you. > "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. It seems to me that this "right to left rule" can only be accurate in the context of a sequence of monadic verbs with a noun argument. And in this case there can be no ambivalence. But I do not think that was your point? -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
