🚀 go-pugleaf

Stephen P Spackman:
   J is just willing to reinterpret what are the "cells" and what is
   the "carrier" on an operation-to-operation basis - one of its few
   really excellent notions, that other languages need to pick up. You
   are right, though: this information should be encoded in the
   definition of the operator, not at the callpoint.

Um... but J does encode this information at the definition of the
operator.  It's just that J makes operator definition so easy that
operators can be defined and used in place.

I happen to like this feature.  Anonymous function declarations can be
very expressive.

   (And our interlocutor is evading an important issue by saying that
   "names in J are no more significant than parentheses", because they
   seem to have strange interations with the more tightly-binding
   modifiers, like " - or else that " COULD have been in the
   definition).

huh?

   |A similar function can be defined for PSCAN (Fortran already uses
   |the name SCAN for something else) which could be written to
   |perform the same `adverb' that `\' does in APL and J.  The
   |exception would be that the associativity flag would be limited to
   |left-to-right or right-to-left (scanning doesn't make much sense
   |as a completely associative process - partial results appearing in
   |any order?).

   Makes perfect sense, actually: this is the precise structure of a
   search tree (under the interpretation I gave above). Just because
   BOTH FORTRAN and J are too broken to represent trivial data
   structures....  ;-).

I'm sorry, even after reading your search tree structure (elided to
try and keep the reading load down) I'm not sure what it is you think
is missing from J.

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>