Hello Don, Your expression: 3+ 2- 7* 5^ y M M M M
reminds me of the efforts in the Concatenative Programming Language [1]. Now, to ask a question from a different stand point - would you like to see the concatenative programming paradigm offered in J? And would such an offering come close to what you see in S? Here is what I see: (1) Tacit programming in J is a powerful paradigm but as many have already remarked in this thread, it does have a steep learning curve. (2) One important design goal of Concatenative Programming is to represent composition as concatenation. Implementations of Concatenative Programming uses a stack paradigm, left to right evaluation and strict post-fix notation for the operators. In order to get the arguments in the right place, there are interesting stack operators that copy/move the arguments.(I am stating what I know - please correct me if my understanding is not right). (3) The stack programming paradigm has a certain simplicity (just like pipes in unix shell for e.g.). But for non trivial programs, I expect there will be a certain mental gymnastics that is inevitable due to the evaluation semantics. And this deterministic evaluation requirement brings with it the 'syntactic noise' in the language. (Here again the proponents would like to argue that it is a necessary complexity for the evaluation semantics and I accept that position.) (4) The concatenative paradigm has a small but passionate group that designs and discusses the merits of the concatenative programming style. I am not sure if this programming style is main stream yet. (5) Personally, I think the concatenative programming paradigm is simpler in its 'point-free expressions' as opposed to tacit J. However at the level of real use, I have used J for interesting experiments. So far, I am happy with what J can do for me! Unfortunately, my experience with Joy, Cat etc is not enough to comment on it. Regarding concatenative programming and J: (a) Steve Apter seems to be creating many such languages based on K. He uses K to program an interpreter for his concatenative languages. But clearly these are not native K extensions. (b) My guess is that if you want to embed concatenative programming paradigm into J, there will be a trade-off between 'natural' math expressions and concatenative forms. I see J's tacit evaluation paradigm as different but with a design principle to support infix notation while concatenative operators are post-fix. (There are possibly more differences here - I am suggestive not exhaustive in my comparison) (c) Is there a way in which infix operators can be defined in concatenative languages? Will that bring with it the elegance that is sought here? I do not know. This is an interesting discussion on the design of tacit J. I am sure learning a lot from these discussions!! Regards, Yuva [1] http://en.wikipedia.org/wiki/Concatenative_programming_language On 4/27/09, Don Watson <[email protected]> wrote: > Hi Raul, > > I think our differences may stem from looking at different sides of the > elephant. You see the trunk, I see the legs - or vice-versa. Both views may > be reality, just different views of reality. > > You state: > > "I do not understand your continued emphasis on monadic verbs in this > discussion." > > This is how I view it. I will take a very simple explicit J expression > with only dyadic verbs, constants and a right argument: > > 3+2-7*5^y > > You can break this up as follows: > > 3+ 2- 7* 5^ y > M M M M > > I have placed an M under each constant followed by dyadic verb, because > together they are the equivalent of a monadic verb. Tacit J does exactly > this with the expressions: 3&+, 2&-, 7&*, and 5&^. That is why I am > looking at any arithmetic or language with the right to left rule as a > stream of monadic verb expressions. In the revised tacit J that I am > proposing, I am also dealing with a right to left rule; so I also see a > stream of monadic verb expressions in my tacit J. If I turn the explicit J > into revised tacit programming, I have: > > Verb=: 3+ 2- 7* 5^ > M M M M > > So my new verb is a stream of monadic phrases. > > That's the trunk I'm looking at. > > You state > > "Your assertion that J tells whether a verb is monadic by its > position in the stream is just plain wrong. > > It is perfectly possible to have a monadic verb in any of the even positions > provided there is a cap to its left. It is even possible to have a cap with > a verb which may be used in either a monadic or dyadic context, and the cap > forces use of the monadic form." > > Your view says: "The cap is a useful facility because it enables me to > to place a monadic verb where a dyadic verb would be expected > otherwise. > > My view says "There is a problem because tacit J is expecting a > dyadic verb where I want to put a monadic verb. The cap is a patch > that solves this problem. > > I believe that we are both right. > > You state: > > "There is a clear and simple sense in which the train follows the right to > left rule. The first three verbs from the right are executed with reference > to the arguments of the train, then that result is the right argument of the > next verb in the train. So we have for the odd number of verbs case > v v (v v (v v (v v v))) > where each parenthesis reaches out to the arguments of the call of the train > and each pair of verbs and its right parenthesized group is treated as a > fork. > > For the even number of verbs case we have a hook > v (v v (v v (v v v)))" > > I agree, except that it isn't proper right to left, because you can't > use fork functions to write it as: > > F(G(H(K(y)))) > > The problem comes when you want to add an extra monadic verb > on the way: > > v (v v (v v v(v v v))) > > Without the cap, the system will wrongly interpret it as: > > v v (v v (v v(v v v))) > > So I see the cap as needed to patch a problem. > > You state: > > "I cannot see how your (M1)DM2 expression as the definition of a train would > work if all of the verbs are dyadic." > > In the definition above: Verb=: 3+ 2- 7* 5^ there is nothing > but > dyadic verbs. The constants could, of course be replaced by a named noun or > a noun phrase: > > Verb =: a+ (n^5)- 7* 5^ > > However since we should try to avoid global variables, we might also use > the exression: x+ (n^y)- 7* 5^ y This would convert in revised tacit J > to > a dyadic verb: > > verb=: ([)+ (n^)- 7* 5^ > > The ([) is perhaps a patch in my tacit programming, because the right to > left rule - all basic monadic verb expressions - needs a parenthesis to the > left > of a verb to tell it is dyadic since the noun has been taken out. > > Don > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
