🚀 go-pugleaf

In article <ROCKWELL.92Apr8001532@socrates.umd.edu>, rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|> [...]
|> Manipulation of odd elements and even elements is a problem
|> significantly different from copying elements in place in the array.

My example didn't copy _any_ elements `in place'.  The destination 
locations were completely disjoint from the source locations.

|> [...]
|> Hmm... and I consider Fortran's to be crippled because it forces me to
|> restrict my problem space in what I consider an arbitrary fashion.

Fine, I agree that the language sometimes forces you to make restrictions
which you do not want.  However, it appears that J doesn't allow me to
make those same restrictions when I _want_ to do so.

|> [...]
|> But "typeless" is a misnomer.  The type of an expression is sharply
|> limited by the operations performed on the results of that expression.

The word `type' means any static attribute which is associated with
an identifier in such a way that _every_ occurrence of the identifier
in a given scope has that attribute.  The word `type' has no meaning
at all if all attributes are dynamically alterable.  In this case
you _may_ decide to apply the word `type' to certain properties of
_values_, but such a distinction is not useful.

You have been juggling semantics rather creatively to claim that
every assignment actually introduces a new scope.  If this is true,
then it saps the meaning of the word `scope' to nothing.

|> [...]
|> >  |> The advantage of this rule is 'rank' has a consistent and easily
|> >  |> understandable definition which is usable with any operation in
|> >  |> the language.  No exceptions are needed.
|> 
|> >  I still don't understand what it does.  Does it apply to the vector
|> >  or to the array?
|> 
|> Well, neither.  It applies to the operation.  The derived operation
|> then applies to the vector or to the array.

Well, I can see that this "easily understandable" definition is too
complex for you to describe in a news article.  I'll just have to 
get used to the fact that the quote symbol is used by J to do something
arcane and hidden (which appears to has something to do with transposition,
but I can't be sure).

|> 
|> >  Exactly.  I _wanted_ the function to be more verbose so that I can
|> >  read the code several months later (or read other people's code)
|> >  and have a chance of seeing what it means.  It also gives more
|> >  explicit information to the compiler for optimization purposes.
|> 
|> Verbosity in and of itself does not achieve clarity, and can hinder
|> insight into the problem.  [...]

Terseness in and of itself does not achieve clarity, and can hinder
insight into the problem.

The trade-off between being terse and being verbose is the effort
to find the thin balance being succinct.  The problem actually has
two dimensions.  There is the spectrum from densely packed information
to loosely packed information.  And there is the spectrum running
from underspecification to overspecification.

APL and J both make the mistake of assuming that density is desirable.
Lots of small operators densely packed together inhibits legibility.
Especially if these operators have no mnemonic value or are composed
of the same symbols as other operators with different meaning.  For
example, I'm told that the J operator for the Boolean `and' function
is `*.' and that `+.' is the `or' operator.  The thing is that `+.*'
is the inner product, and who knows how many other operations use
dot with plus or asterisk (and other symbols) to mean completely
different things.  

I've seen APL experts spend 30-40 minutes studying a _single_ line 
of APL before they thought they understood what it did - in fact, 
this was common.  In fact, the _less_ densely packed the language's 
notation is, the better (within reason).  Certainly, operators, function
names, and other syntactic objects should have mnemonic value (and they 
need to be large enough tokens that this mnemonic property is visible).  
The most common operations can be small - but conventional notation already 
has such operators defined.  Less common operations need larger names.

The other aspect of this question is the degree of specificity that the
language requires/allows.  Here the _user_ must be allowed to decide 
what degree of specification is needed.  Conventional Fortran _requires_
all arrays to be of known base type and fixed rank.  For the overwhelming
majority of uses, this is an appropriate constraint.  Our extension
provides mechanisms for declaring variables whose rank and/or base type
is part of the _value_ of the data.  Since this is actually an unusual
need, we require explicit declarations of the fact that rank or base
type are variable.  As far as I can tell, in J the rank, base type,
or even whether the thing is an array at all cannot be declared
statically.

To be sure, Fortran requires you to be overspecific.  It seems to me
that J doesn't allow adequate specificity.  Further, there is a balance
point at which most programs exist.  Additional specificity beyond
this balance point should require explicit declaration.  LESS specificity
than the balance should _ALSO_ require explicit declaration.

|> [...]                                      Further, the example was
|> >  stated as requiring a function to handle arrays of rank 4 through 7
|> >  - without an run-time test, how does your J code insure that arrays
|> >  of rank greater than 7 aren't incorrectly passed?
|> 
|> Well, since no actual operation has been specified, it's rather
|> difficult to provide code for it.  However, if the operation was
|> called 'operation', I could use:
|>     operation"7
|> to make sure that arrays of rank greater than 7 aren't incorrectly
|> passed.

And this is not a run-time test?  How is it applied?  Is this the
form of the declaration of `operation' or is it how I must reference
`operation' if I want the test applied?  If J were less dense, I 
probably would have been able to answer some of these questions from 
the example itself.

J. Giles