Consider the following J program:

echo =: (1!:2)&2

huh =: 3 : 0
f1 i. y.
0 0$''
)

f1 =: 3 : 0 " 0
echo 'f1 > f2 ',": i. 1+y.
f2 i. 1+y.
)

f2 =: 3 : 0 " 0
echo '  f2 ',": i. y.
)

If we call huh with 1, it does what we expect:

   huh 1
f1 > f2 0
  f2

but if we call it with 2 ....

   huh 2
f1 > f2 0
  f2
f1 > f2 0 1
  f2
  f2 0
  f2
  f2 0
f1 > f2 0
  f2
f1 > f2 0 1
  f2
  f2 0
  f2
  f2 0

!!!

The order of side effects produced by function arguments to operators
can not be guaranteed; functions are applied to cells in fortuitous order,
and may be applied multiple times to a cell.

J. Storrs Hall writes on Thursday, October 22:

Interesting example. What were you going for with the "0 in:

Applying a function once, when the result is going to be thrown away,
might
be an accident.  Applying it twice smacks of carelessness...
-j

ps -- if you don't care about side effects, there's a really good
optimization I
can tell you about for lines of code that don't contain an explicit
assignment...

It's not carelessness, I think.  Multiple evaluation occurs when the
verb produces different shapes from the cells; as soon as the
interpreter realizes this it goes back and reruns the verb from
the beginning.  There may be other times I don't know about.

I still think the language should provide some cases where
multiple evaluation is guaranteed not to occur.  For example,
some verbs are defined ONLY in terms of their side-effects.
With the rule Roger gave, the execution of

  (1!:2) 'tata'

is defined as writing an undefined number of copies of the string to
the file.

Henry Rich

I wrote

Henry Rich (Seymour Glass) wrote

One of the first optimizations that goes into Lisp compilers (and often
put into interpreters) is an evaluator flag saying whether an
expression's
value is needed.  Such a flag would have obviated the whole problem
(not to mention great wastes of time and space in some other cases).

It's another example of the schizophrenic nature of J -- I often get
the feeling that whoever designed scripts never talks to whoever
designed expressions.  Try typing
if. 0 do. 'no' else. 'yes' end.
into the interaction (*.jx) window...

Hear, hear!!

(i.e. I agree entirely...)

--j

Henry Rich writes on Saturday, October 24:

Actually no.  This would be a valence error as the monadic form
of file write has an empty domain.

In the dyadic case, writing once or writing a number of times have
the same result and effect.

Roger's never talked to me about how it works, but I think there's more
to it than you have mentioned.  The verb result has to be put somewhere; a
reasonable design would be to evaluate the verb on one cell, see what
shape & type you get out, assume all cells are going to produce that
shape & type, allocate space for the entire result, and then evaluate
the rest of the cells.  This will be fastest in most cases.  If a cell's
result comes back with a surprise shape, you have to reallocate the
output area: a reasonable decision might be to restart the verb using
a routine that allocates each cell's result separately, rather than trying
to save the results already computed.

It's not a script/non-script thing: you can't type if. in a script either,
unless it's part of an explicit definition.

Henry Rich

Yes, I typed hastily.  What I meant was

    'tata' 1!:3 <'undefinedfile'

which exhibits the problem, no?

Henry Rich

That was inaccurate and ungrateful.  Roger very helpfully told me long
ago that a problem I was having with reevaluation probably stemmed
from cells' returning different shapes.  The rest is my supposition.

Henry rich