🚀 go-pugleaf

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

Look at SELF. Hell, look at the internals of a competent FORTRAN
compiler. You're thinking in the stone age! :-)

It's not a question of if they could according to the language spec,
it's a question of whether they could according to the programme text
as interpreted under that language spec, and those are poles apart.

|addressed the important issue of separate compilation (many
|vendors don't like to distribute source but are willing to
|distribute relocatables).

What does it matter? Who can read J? :-)

Separate compilation and optimisation are mutually incompatible
anyway, so don't worry about it in THIS context - in fact,
optimisation without prior execution is undesriable, too, so a decent
system with good performance is going to look a bit interpretive....

Have you considered distributing the intermediate code instead?

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

...reaches for asbestos-type trousers...

What, you think I'm defending J, just because I don't like FORTRAN?
They're practically dialects of each other anyway, with their
array-o-centrism, type-o-phobia, line-oriented syntax, proliferation
of system-reserved mechanisms, encouragement of semantically
inexplicable floating-point arithmetic and general inattention to
actually solving the problem....

:-)

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

Gotta be one, if you're going to go the directional route. But you can
always use the end element of the array if you are SURE that's what
you want.

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

"Random", unlikely. "Underspecified", you bet. "Implementation's
choice", quite likely if the machine is a multiprocessor, a vector
machine, or....
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------