> x y m n u v are temporary variables.  They are pre-initialized
> with argument values in some contexts, but that should be the
> only way they are special.  (We apparently have a bug where
> this is not the case -- but that looks like nothing more than 
> a bug.)

I was going to disagree with this, but not I'm not so sure.

I can see the reason for replacing x. (or x) by its value:
if you pass it into another explicit definition, whether
as an operand to a modifier or encapsulated in a gerund
such as (+`x), the name has got to be replaced, because
the value changes when the explicit definition is invoked.

So, are   x y u v m n  special in this regard?  Yes, in that
their names are reassigned when a new explicit starts; No,
in that the same sort of problem happens with any old
private name.  If I have

  p =. +
  (p adverbdef) y

I will probably come to grief, because p will not
be defined in adverbdef.

Would there be any problem with saying that any local
name will always be replaced by its value?  In other words,
all local names will be treated as x y etc are now, and for
much the same reason: that they are messed up when a
new explicit definition is invoked.

I don't use local verbnames much, but when I do, I often run into
this problem I am talking about, and the fix is to make the
names global: an ugly solution as it makes global names when I
really only want local ones.

If I have x defined as a global name, and I execute

  (x adverbdef) y

from immediate mode, what should be passed into adverbdef?
I think it should be the value of x, not the name, since
the name can never get substituted with the correct value.


So I am suggesting that names should be stacked by value if
they are nouns OR if they are local names OR if they are
the special names x y etc.  In the current implementation
they are stacked by value if they are nouns OR if they are special
names.

Henry Rich



----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to