🚀 go-pugleaf

In article <STEPHEN.92Apr9220641@estragon.uchicago.edu>, stephen@estragon.uchicago.edu (Stephen P Spackman) writes:
|> In article <1992Apr9.003132.5175@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
|> [...]
|> 
|> |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).  [...]

Well, no.  Not always (or even usually).  If I want that to be allowed,
I want to have to explicitly denote that such a thing is being done.

|> [...]
|> |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.

Yes, provided the declaration mechanisms are in place to make 
propagation of the required information possible.  In J it is 
apparently possible for type information to come from I/O.
Certainly two different paths through the code may define 
these characteristics differently.  How do you apply static
tests to things that can inherently vary at run-time according
to the very definition of the language?  And we haven't even
addressed the important issue of separate compilation (many
vendors don't like to distribute source but are willing to
distribute relocatables).

|> | [...]
|> |	 REDUCE (FUN, ARRAY, DIM, DIR)
|> |[...]                                                    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.

Good point.  However J doesn't appear to have this property either 
(or no one has seen fit to describe it).

|> [...]
|> 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).

Ok.  This could be defined as the operation of REDUCE.  You'd have
to add a way of passing the identity element (and a way of stating
that there isn't one).

|> |[...]            (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....
|> ;-).

Well.... Maybe.  I still don't see any practical value to scan results
in which the partial accumulations are in random order.  But there may
be some - I'll take your word for it.

J. Giles