On Tue, May 19, 2009 at 8:01 AM, Don Watson <[email protected]> wrote: > O.K., let me try another tack. > > If an inexperienced J user could add features of tacit J gradually, > the J learning curve would be smoother, tacit programming would > have broader use and J would have broader appeal. I am going to > propose one addition in an attempt to do this.
I see this as being analogous to teaching pidgin english as a way of introducing english grammar. (In essence, the only difference between explicit and tacit programming is grammatical.) Pidgin english might be useful in some contexts, but I do not see schools using it in grammar classes. Instead, they usually find simple examples to work with before jumping into advanced topics. That said, if you wanted, you could write your own parser which implemented whichever grammatical rules you wanted to be using. You already have ;: which will take the text of a sentence and give you its sequence of words. And, you have a fairly clear description of how the current parser works, in section IIE of the dictionary. http://www.jsoftware.com/help/dictionary/dicte.htm So, be warned: I am entering this conversation with serious doubts about your proposal. > The parentheses around the whole expression do two things: > > 1) They define the where the argument for the tacit expression (- +/ % #) > is to be found. > 2) They define the content within the parentheses to be a train of forks > and hooks. > > What would make the transition to tacit J easier for inexperienced J > J users would be the first outcome without the second, to define > where the argument can be found while allowing the total expression to > remain right to left J code. One way of doing this would be to include > the whole expression within Inside-out parentheses: Let us take a simple example: n=: 1 + 1 Now let us add parenthesis n=: 1 (+) 1 If I understand you properly, you want to change J so we must instead use n=: 1 )+( 1 so that we can tell that + wants to get its left argument from its left and that it wants to get its right argument from its right. But if we take a slightly more complicated expression: n=: 1 + 1 + 1 then things start getting confusing: n=: 1 )+( 1 )+( 1 Before long, I think we would be having problems distinguishing inside out and rightside out parethesis. This seems to be especially the case when tacit verbs contain parenthesized tacit verbs. but also when explicit expressions use tacit verbs. Also, consider something like: ()+/%#(1 2 3)^2 Here, we have a monadic tacit verb. But we have an inside out parenthesis on its left indicating it gets its left argument from its left side. But it has no left argument. How would I explain this to a student asking me about why he has to use inside out parenthesis? Or, even worse, imagine if that was supposed to be a dyad instead: (3+4*5)%,-(1 2 3)^2 I am not even sure how I would instruct the computer that I wanted the answer 529 169 93.4444 361 225 121 and not the answer _23 _5.75 _2.55556. Currently, J has no such difficulty: (3+4*5(%,-)1 2 3)^2 529 169 93.4444 361 225 121 Anyways, I know I would be confused by a mix of inside out and right side out parenthesis. I would probably be confused by inside out parenthesis standing alone. )%: )+/*:)- +/ % #(( % <:#( 1 2 3 If I might take a step back from your proposal and try to address what I see as the real problem: In my opinion we do have a problem with ascii -- it's rather ugly and does not give us very many distinct characters to work with. When unicode gets sufficiently adopted that everyone can use some subset of utf-8 without having to worry about bom or mime types or editors or keyboards mappings or font installation, then this problem will go away, and J can be modified to use those characters. Right now, however, the only universally viable subset of utf-8 is ascii. -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
