Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!news.uu.net!spool.mu.edu!news.cs.indiana.edu!ux1.cso.uiuc.edu!csrd.uiuc.edu!sp27.csrd.uiuc.edu!jaxon
From: jaxon@sp27.csrd.uiuc.edu (Greg P. Jaxon)
Newsgroups: comp.lang.apl
Subject: Re: Do I really need a loop?
Message-ID: <1991May22.162856.18418@csrd.uiuc.edu>
Date: 22 May 91 16:28:56 GMT
References: <3970004@hpwrce.HP.COM> <15160018@hpdmd48.boi.hp.com> <1991May15.134305.10894@yrloc.ipsa.reuter.COM> <1991May17.031707.27992@cshl.org> <1991May17.215809.27935@yrloc.ipsa.reuter.COM>
Sender: news@csrd.uiuc.edu (news)
Organization: UIUC Center for Supercomputing Research and Development
Lines: 67

rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
>Perhaps we should be a bit gentler, and just suggest that those APL dialects
>of yore have failed to adopt general principles of extension, and have
>added special cases for many primitives instead, following the lead
>of the Fortran 90 designers...

I don't see any 'failure' in the quest for generality in 'APLs of yore'.
Neither do I see very many 'special case' inventions, although sometimes
in a complex web of design issues a general plan is only deliverable in
the form of special cases.  Axis brackets and index brackets turn out to
be clumsy syntax in a pure realm of applicative programming, and the rank
operator is an admirable invention.  Of course it can be adopted directly 
into APL, but its usefulness as a language component comes partly from
how all its companion primitives are defined.  And so it lives most
comfortably in J.  APL could become J? -- No, the design of APL is
essentially complete, the design space split into the APL2 and Dictionary
variants, which explored DIFFERENT design goals, both succeeded at their
goals to the extent possible within the existing framework of APL. 
Who was following Fortran 90, Bob? No one I was talking to!

APL users could become J users. -- Yup some will, maybe J will be so
good that most APLers will switch.  That's the way languages and marketplaces
evolve.  

>I think the key to J and rank is that the SAME expression works for ANY
>verb, whether primitive or user-defined. This is what sets it apart from
>APL2 and other such dialects of APL. This makes the language easier to 
>learn and use than APL2, simpler to implement, and more general.

>For example, I think one of the APL2 gurus suggested adding vectors to
>matrix rows by doing (pardon me if I get this wrong, please) v+[1]m.

>Swell. Now, replace the + with a user-defined function whose only contents
>is +, and tell me why:  v foo[1] m doesn't work. 

The early APL2 prototype defined an axis operator that used the syntax
you suggest, and I believe supplied the definition you expect.  APL2 was
most relentless in introducing the 'principle of substitutability' into
the APL language design, so your point has not been lost.  I don't think 
that SUBSTITUTABILITY between primitive things and user-defined things
is 'what sets J apart from APL2'. 
 
I'd answer that APLB provides two ways for a user to write a 'function whose
only contents is +'. 1) $Z is A FOO B [1] Z is A + B$ and then inform
the interpreter that its 'rank is 0 0 0' by writing FOO" for +.  In
APLB,  V FOO"[1] M  <->  V+"[1]M  <->  V+[1]M.  2)  Pass + as an operand
to a user-defined operator $Z is V (FOO GOO) M.  When you say V +GOO M
FOO becomes +, and can be treated in the same way that + can.  So on
line [1] of this operator (or suspended inside it) you can utter the
magical incantation  V FOO[1] M and get the Middle Product feature
built into + to do your work.   The issues were not just syntax and
its extendability... (P.S. Dave Liebtag: Can APL2 do these two things?)

When I was at work on these things the language treated primitives
differently from user-defined things because it could know more
about the properties of the primitive's definition. It could know the
'rank' in the J sense.  It could know the 'identity function', and
whether the function was associative, commutative, etc.  Rather than
ignore these important properties when definining the operators, APL2
was willing to use them where they were available, and wait for a
language extension (like rank) that would help a user include these
properties when defining his/her own functions.  
  

Axis is a syntactic lemon. It'll never make bordeaux wine, but it can
make lemonade!
Greg Jaxon