🚀 go-pugleaf

In article <STEPHEN.92Apr6203136@estragon.uchicago.edu>, stephen@estragon.uchicago.edu (Stephen P Spackman) writes:
|> [...]
|> Don't yopu detect the circularity in your own reasoning here? You are
|> opposed to user-defined operator syntax because it cannot have the
|> natural precedence for the language, but the reason it doesn't have
|> the natural precedence for the language is that it was specified that
|> way. Justified, of course, by the fact you don't really want to use
|> it....

There is no circularity in my argument.  The `naturalness' of a
precedence ordering derives from mathematical notation _outside_
of programming.  Fortran adopted those precedence rules that 
mathematicians and scientists `naturally' use themselves.  If
there are additional widely used operators in mathematics and
the sciences that can be represented in ASCII in a reasonable
way, I'm perfectly willing to adopt the precedence rules that 
are `natural' for those as well.

|> [...]
|> Your position CAN be justified, along these lines: Ok, centuries ago,
|> we screwed up. We wireed in precedence and it louses up user-defined
|> operators, and heaven opnly knows how we didn't see it coming. But the
|> mistake has been made, we can't trash all that extant code, and
|> operator priority declarations have been tried and they're a
|> nightmare.

I disagree.  I think the conventional notation is quite useful and
very mnemonic.  I don't think that `we screwed up' centuries ago
at all.

Further, I don't think that arbitrary additional operators should 
be given varying precedence.  There is a compromise here.  Too few 
precedence levels requires excessive parenthesization to make the
expressions legible.  Too many precedence levels do the same (since
no one remembers all the rules).  There needs to be a few precedence
levels for the most common operators.

|> [...]
|> In any event, how does adding a general case impair performance for
|> the already-identified common case? Are you really planning to write
|> compilers THAT DUMB?

What `already identified common case' are you referring to?  The
description of J has as yet included no methods at all of programming
anything but the general case.  The issue isn't about `adding' a
general case - it's that there is no way to explicitly specify
the more common cases where you _know_ in advance the ranks of
all your arrays.

And, from what I've heard of performance figures, J is quite slow.
So, whether or not _I_ plan to write dumb compilers - somebody
does!

|> [...]                                    (look at it this way: out of
|> FORTRAN and J, which one are you going to have better luck learning in
|> two hours? My bet goes with J *even though* it is cryptic and - not
|> counter-intuitive - counter-historical).

My bet goes with Fortran.

|> [...]
|> Actually, I think the idea was to change the LOCAL INTERPRETATION of
|> these arrays and not their FORMAL TYPES at the callpoint. The
|> introduction of tags, as you suggest, would actually result in
|> breaking many operations - suppose, for instance, that the final,
|> 7-dimensional array needs to be considered as 4+3 on one line, and
|> 3+3+1 on the next? [...]

That would violate the assumptions in the original example.  We were
presented with the problem of performing operations on arrays which
could be anywhere from rank 4 to rank 7.  Only the rank 7 arrays
could ever be treated as rank 3+3+1  -- hence whatever operation
needs to treat it that way can't be part of the common operations
for all these possibilities.

|> [...]
|> Both these languages suffer from far too much historical baggage, but
|> surely there's still room for some POSITIVE dialogue?

But, I don't consider blanket condemnation of `historical baggage'
to be a positive step.  Some historical decisions exist because they
are more effective than the known alternatives.  I think operator
syntax is a case in point.  Too many operators and precedence levels
makes the language too complicated.  Too few makes the language
flat and bland (with lots of needed parenthesis).

J. Giles