On 10 April 2011 19:55, Raul Miller <[email protected]> wrote: > But this is not K. If K semantics were intended by the dictionary, > and they were not explicitly specified, that would be wrong. But why > should the J dictionary have to assert that J semantics are to be > used?
I have already explained that: `applies between' does not specify direction (L-R or R-L). We know that the order is R-L for an expression like y1 u y2 u ... u yn, but not for u/y. / is an operator that has to be defined as strictly and formally as any other. If / is meant to induce a R-L order of applying a verb, then /'s definition should better be explicit about that -- which it isn't. And K was only mentioned as an evidence that the order of application induced by u/y is not automatically the one of y1 u y2 u ... u yn: in principle, it could be any of L-R or R-L, and it is the definition of / that decides which one it is. There is no implicit semantics of / -- it has to be defined, whatever the language. >> I would have no doubt if the definition said, e.g., >> `u/y, for y = y1 ... yn and n>1, is equivalent to the expression >> y1 u y2 u ... u yn'. > > Why would you know, in this case -- but not the other case -- that the > dictionary was not talking of a K expression? I don't understand what you mean here. Of course in both cases we are talking of J expressions. The point is that my example sentence above *clearly and explicitly* defines the order of evaluation of u's application within u/y, to be the order of evaluation of the expression y1 u y2 u ... u yn. Then, since the latter is R-L, the former is also R-L. Without explicitly sayng that, we simply cannot be sure about what exactly u/y does -- and this is why J's definition of / is unclear. > I suppose you are arguing that J should reject cases of u/y where y > contains elements which are not in the domain of u. I am not proposing a change to J. I am only making two observations. First, /'s definition is not entirely clear -- it leaves room for guessing. Second, /'s actual operation has certain intricacies and anomalies which I see as a result of / not allowing for an initial value, in addition to the list, to take part in the computation. Indeed, Haskell's folds, K's `over', Lisp's reduce, etc., which do accept an initial value, present no such problems. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
