Don, I seldom get to the northern hemisphere, but at a conference on J in the early 90's there were many present who would have liked some things different. They recognised there were problems with the language. They did admire the simplicity and richness which had been achieved, but were open to improvements. I believe Jsoftware still are and they continue to make improvements in the detail of the language. However most users do not want those at the cost of losing some of the strong features which it has. One of the riches of J is that it readily encompasses so many of the traditional programming paradigms. You can write J in the imperative or 'explicit' style. You can write in the tacit or functional style. You can can use an object oriented paradigm as in the J object dictionary package. You can easily switch between them in a single project. It gives astonishing flexibility.
For me at least, defining a function and applying or using that function require some different concepts. It is not surprising therefore that there is some difficulty in moving between them. Within the tacit form [ and ] represent the left and right arguments of the newly defined function unless of course they are incorporated within brackets when their referents will depend on the context. This function in the train is very useful simply because in the odd positions from the left in the train it permits an almost arbirarily complex way of involving those arguments in the computation. Looking at your original paper s.doc S focuses strongly on monadic functions. Trains essentially exploit the almost default perspective of J that functions are dyadic. It gives extraordinary power. > I think you will agree that elegance and simplicity require rules that > are simple, powerful, logical and small in number. The rules in explicit J > exactly fit these criteria. I agree with you entirely with regard to > explicit J. I have no wish for the rules of explicit J to be changed. > However, the rules in tacit J may be powerful, but they are not simple, > logical or small in number. I do not see them as complex as you do. Your perspective on explicit J I think focuses on rule 1 in the section of the Dictionary dealing with parsing and execution. There are four more rules, and a parsing table and to suggest that the rules of explicit J are simple just does not face the facts. The rules of tacit J are simpler. Your examples are nearly all trains of verbs or trains of the verb generated from an adverb. For these the rules are very simple as I outlined briefly. > I originally called what I was proposing S, because I wanted to > emphasize that I did not want to interfere in the work of J users. This > would be an extra and separate facility. However, this has probably caused > confusion. I will now call it Revised Tacit J. These are the complete > rules > for Revised Tacit J: At this stage lets stick with S until there is a community who want to think of this as an appropriate revision. > > In the explicit J expression: > 1) Wherever there is a y to the left of a right parenthesis, remove it. > 2) Whenever there is a y to the left of dyadic verb, replace it by (]). > 3) Wherever there is an x replace it by ([). Consider h(g(x f y)) which is a simple expression with some redundant parentheses rule 1 h(g(x f)) rule 2 does not occur rule 3 h(g(([)f)) The problem with this tacit expression is that it is a hook which calls a monadic function which looks for a dyadic argument. I think you need some more rules. > This has 3 rules, which are simple and small in number. It is logical, > because at execution time the system: > a) Can find all right parentheses and put the right argument to the left > of > them - from where y was taken. > b) Can find all "]" and place the left argument to their right, > ````from where x was taken. > > Now give me the rules for your tacit programming and show them to be fewer > in number, simpler, more elegant and more logical. Provided the tacit expression is a verb train the rules are simple. (1) Each odd verb from the right accesses as arguments the arguments of the function (2) Each even verb from the right accesses the result of the function on its left and result from evaluating the expression on its right (3) The rules are the same for the dyadic and monadic verbs in odd positions (4) To insert a monadic verb in an even position use [: to its left (5) To insert a monadic verb in an odd position use ([: v same) where same is one of [ or ] and v is the verb name if the train is to be called dyadically. That is enough to get beginners going. (6) Where an adverb is used the resulting verb is counted as a single element in the train +/%# provides an example of this and extends the range of tools > __________________________________________________ > > To continue, the vocabulary of J has other rules: > > 1) Use %: for square root. > 2) Use *: for square. > and so on. > > I have not seen explained why these are needed. It may be > obvious to many of you, who weren't bothered because you could > see through it to the value of J, but it needs to be explained to many > others, for whom extra rules are a barrier. If you want J to spread, > it would be helpful to do something about it. It does need a way of specifying its functions, and using the special characters of the keyboard is an interesting solution. As Bjorn noted you can use load 'primitives' to give the verbs all names, something I recommend for beginners. > > I am going to look into this and will be back. I think that if there > were > an introductory version of J in which the most frequently used and > earliest used primitives could be given the same symbol as in > Mathematics, it would help to get people started. They could then > move to the two character symbols whenever they were ready. But I > will have more to say later. The commonest primitive in J is probably ',' . What mathematical symbol does that represent? Ken wrote his APL book to provide a language for describing algorithms. He used a new notation because Maths did not have neat symbols for the things he wanted to do. J is just the latest version of what he was trying to do. It is a tool for executing mathematics. > _________________________________________________________ > First you get champions who are able to quickly see the > advantage. You don't force them, they just get enthused and get going - > bottom up. When it has spread, that's when those at the top get > interested. > APL spread like wildfire. You have to ask yourself "Why hasn't J spread?" > It isn't because you can't convince those at the top, it's because you > can't > convince enough at the bottom. There is no doubt that this is a potential way of getting the adoption you and others seek. > > > I don't have a problem with using words where they help and are needed. > My problem is using them when they are only needed because something > is wrong. Mathematics does not have all the tools or symbols for appropriate execution of many of the expressions it derives. Avoiding words I think makes J look more esoteric than it is. > _______________________________________________________ > > You state: > > "There clearly is something worth doing, but do not expect to persuade the > whole J community. All that is needed is a small group who actually do > the > things they think are needed." > > Nothing gets done in life because everyone agrees. There are some > people > who are committed to the same idea and will always agree. There are some > who > are strongly against the idea and will never agree. In the middle are a > group who will listen and either be convinced or see the flaws in the > argument for change. Which way the central group goes decides the issue. If that means we stay with a purely symbolic form then it will have the lack of popularity common with school mathematics classes. For a lot of children capable of logical quantitative thinking a symbolic presentation is sadly a turnoff. I think we need a convinced group of J users who are willing to use an interface to the present language which does not prove a turnoff for new entrants. I am perfectly happy for those who love the symbolic form to continue to use it. They are one group of pioneers using the language - but we need other groups as well. > I must have been one of the fortunate ones, because my education always > taught me to ask why. When I looked at tacit J for the first time, I asked > myself why I can write: > > +/ *: 2 6 8 9 > > but have to write: > > sumsq =: +/ @: *: > > Why is that @: necessary? It was and is a good question. Merely writing +/ *: does not tell J how you want the functions combined and applied to the data except in the simplest cases. It has some defaults but those may not always give the answer you want. The ditinction between @ and @: depends on concepts which the beginner won't meet initially. I would have written [: +/ *: and stuck with defaults until I asked - why can I not ... > > J documentation is very good at explaining what and how - but contains > very little on why. > ............... > I then subjected your tacit J to the same kind of analysis and > determined why. Someone decided that it would be very concise to write > four > symbols side by side to represent a fork followed by a hook. This is a > very > concise way of defining the deviation from the mean, for example. The > problem is that a one off rule that doesn't fit the rest of the rules > leads > inevitably to a mess. The structure of tacit expressions was not just a case of finding a simple rule. It became a carefully thought out means of expressing function composition. > I have stopped worrying about avoiding confrontation with J users. > This discussion is long past that. J is broken and until it is fixed, > there > will be no expansion of use. You should not have worried in the first place. It depends on how you define broken. Some of us believe that J is the best tool available for many purposes in schools. That some inferior ones out there are currently being used does not mean J is broken. > I am discouraged that tacit J seems to discourage the use of > constants to the left of dyadic verbs, but can live with it. You can > include a named noun to the left of a dyadic verb in tacit > programming as you wish. However, if you wish to avoid global variables > that have to be set before a named verb can be used, then you must > avoid named nouns in the definition of that verb. How would the result of the function be determined if the noun has not been set when the function is used? If you want to carry along an unkown parameter that makes it a different problem. Fraser ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
