🚀 go-pugleaf

In article <1992Apr9.003132.5175@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
||> [...]
||> For example,
||>      f"1 x
||> means that f applies to the vectors in x, and any additional
||> dimensions are processed "in parallel" [with a unique instance of f
||> applied to each vector].

|What I want is a way to state right up front that "every occurrence
|of x in this program is a one-d array" and that "every occurrence of
|f in this program is a function which takes one-d arguments" and have
|the compiler check every occurrence of these two identifiers to make
|sure they obey these constraints.

No, it's just reduced the issue to one of conformance (which is
correct: you _want_ your "scalar" operations to work on homogeneous
arrays, I expect). 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. (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).

|Any language which does not contain mechanisms to declare desired
|constraints cannot do so.  Period.  No matter how verbose you want
|to write your code, the contraints cannot be expressed.

Not true. A compiler CAN extract information from higher-level form
(as in "do this or bust" expressions, e.g.). Check the current
literature, it's in vogue the last couple of years.

|As an example of generality being easy to provide, Fortran 90
|will allow a function to be declared (actually, overloaded) with 
|the following calling sequence:
|
|	 REDUCE (FUN, ARRAY, DIM, DIR)
|
|where FUN is a diadic function defined on the base type of ARRAY
|which returns results of the same type; ARRAY is an array of arbitrary
|rank; DIR is an optional flag specifying whether the reduction is to be 
|done left-to-right, right-to-left or in any order the compiler pleases 
|(it's an assiciativity flag); and DIM is an optional argument which
|gives the axis along which reduction is to take place.  This makes 
|REDUCE a completely general reduction `adverb' in the sense that you
|recommend (in fact, due to the DIR flag, this is _MORE_ general).

But clearly both slightly broken and excessively restrictive: on the
one hand the IDENTITY needs to be specified (in case the array is
empty); and the DIRECTED reduce operator requires only that the
function be in (T x U) -> U (resp. (U x T) -> U), where T is the
element type of the array and U is the result type and the type of the
identity element.

A clearer way of thinking about reduce is that it takes place in two
steps: first it rewrites the array as a binary tree (left-branching,
right-branching, or random, depending on the direction flag) and then
interprets this tree as an expression tree in the restricted language
(FUN).

|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....
;-).

||> [...]
||> Remember, identifiers in J have no more significance than braces or
||> parenthesis do in other languages.  [...]
|
|A property of the language I find _very_ bad and I can't imagine
|why you think it useful.

It's essential to transformational programming and algebraic proof
techniques. You want to be able to substitute equals for equals, and
it really HELPS to have some "equals" to substitute!
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------