Hi, Chris,
I think your comments on the "axis-bracket notation" is a bit
of a cheap shot. That notation is NOT an operator, although
it certainly has some of that appearance, and it WAS one of the
primary reasons Ken and I worked to develop a proper
conjunction to supplant axis brackets, that I introduced into
SHARP APL as the rank conjunction.
The reasons I say that axis brackets are not an operator/conjunction
are:
- its syntax is anomalous. This is annoying
- its semantics are custom-defined for EACH primitive.
This is the primary reason it's a notation, rather than
an operator: its operation on an arbitrary verb cannot be
defined.
My personal favorite example of the complete uselessness of
axis brackets is the APL2 definition of ravel, which grows from
a paragraph for ravel to three pages for
ravel-with-axis-brackets.
- the implementation of axis bracket notation within the interpreters
has to be special-cased (as you noted) for EACH verb.
Rather, axis brackets are a bit of archaic notation that
would have been, were it not for The Installed User Base,
discarded with no regrets. Sort of like cap, in J?
We all make design (and implementation) mistakes;
sometimes we can fix them.
There is no doubt in my mind that J does represent, with
some exceptions, a cleaner and leaner definition of an
array language than does APL. We did learn from the
experience of APL.
However, we might also learn from
the experience of Sven-Bodo Scholz and the SAC
designers, who took the array concepts of APL and
implemented them in a functional subset of C.
They went beyond APL, J, and C in specifying
a formal mechanism to (Gasp!) let a function return
several results (as Dyalog has done). Furthermore,
SAC supports user-defined data types, which neither
J nor APL do. Finally, they realized that nearly all
array primitives, if defined in standard libraries as
SAC code, rather than as bolted-in primitives,
offer substantial advantages to all:
- the language core becomes simpler,
- stdlib-defined primitives are exposed to
compiler optimizers, with substantial performance
benefits,
- extending "primitives" to new, user-defined data types
is trivial for a user to do, and
- if you don't like the supplied definition of a
"primitive", you can supply your own or enhance/alter
the supplied one, adding it to your own private libraries.
This approach allows us to move away from The Tyranny
Of The Implementor, which I personally feel has been
a much greater weakness of the array languages.
Bob
On Fri, 2007-12-21 at 10:11 +0800, Chris Burke wrote:
> Morten Kromberg wrote:
> > However, Mark D. Niemiec wrote:
> >
> >> J has abandoned a lot of the ugly and irregular archaism of APL,
> >> making its syntax more elegant. To wit:
> >> - bracket indexing y[x] being unlike other functions; replaced by regular
> >> x}y
> >> - bracket syntax u[n] being unlike other operators; replaced by u"n
> >> - irregular axis-operator semantics replaced by regular rank-operator
> >> semantics
> >> - many APL primitives (such as rotate/reverse, compress/reduce,
> >> expand/scan)
> >> have two versions with different default axes. J eliminate this
> >> redundancy
> >> by the more general and consistent rank mechanism.
> >> - ; having different precedence from all other verbs
> >> - unique syntax of outer product.
> >> - while APL has some adverb (/ \) and conjunctions (.),
> >> these are special-cased to only work on certain subset of primitives,
> >> while J allows them to be used generally.
> >> - APL's scan operator \ is replaced by the much more useful J prefix
> >> operator,
> >> which can emulate scan (via /\) but the converse is not possible.
> >> - J's tacit verb mechanism allows an entire level of elegance and
> >> succinct expression of functional concepts totally unheard of in APL.
> >
> > J has indeed abandoned much of what one could argue is was shown to "bad"
> > design in original APL (mostly in terms of making it harder to extend the
> > language - not necessarily in terms of making the language easy to use).
> > While APL systems have not abandoned anything due to the installed user
> > base, many more modern alternatives are now available. J grew out of the
> > APL community 20 years ago, and much of the bad or inconsistent design was
> > well recognized at the time. Many of the fundamental ideas like rank, dual
> > and "from" were designed and implemented in SHARP APL (with Ken Iverson as
> > a driving force). So although much "special syntax" involving square
> > brackets and semicolons does remain, some of the items on the above list is
> > are not really fair to APL:
> >
> > - In APL, indexing can be done with "squad" and "pick" indexing (no merge -
> > yet)
> > - Rank was actually implemented in SHARP APL before it appeared in J.
> > Although the APL2 paradigm of axis specification has been dominant in the
> > rest of the APL community, I think we will see rank in other APL
> > interpreters in the future. (And for some expressions, the use of axis does
> > allow slightly more elegant code than rank - even if it is less "general").
> > - It is simply not true that APL operators are limited to certain
> > primitives, at least not in the APL I use. We have user-defined operators,
> > too.
>
> Nevertheless, APL operators are special-cased. For example:
>
> A {gets} 2 3 {rho} {iota} 6
>
> {transpose}[1] A
> SYNTAX ERROR
>
> +/[1]A
> 5 7 9
> sum {gets} {+/{omega}}
> sum[1] A
> SYNTAX ERROR
>
> There is nothing wrong with the syntax in either case - even the error
> message is wrong.
>
> > The one really nice thing J has done that I don't see how APL can follow
> > (due to the installed user base) it to make the first dimension the default
> > for many operations. The interaction between this and notion of rank is
> > really elegant.
>
> The interaction is probably essential. Rank works well in J because it
> is complemented with other features that are not yet in APL - item
> functions, prefix agreement, tolerant assembly. Without these, rank may
> not have the utility that it does in J.
>
> > Dyalog APL has "Dynamic Functions" (lambda-style expressions similar in
> > spirit to KEI's "Direct Definition" ideas), and they SEEM to bring us much
> > of the practical benefits that tacits provide, in a less succinct, but more
> > easily digestible form. This may be because we are reaching for a slightly
> > broader programming audience, with a bit less focus on the mathematical
> > aspects of the notation.
>
> Dfns are very useful and a nice step forward, but they correspond to J's
> explicit definition, not tacit definition, i.e. the following are
> essentially the same:
>
> avg=: 3 : '(+/y) % #y'
>
> and
>
> avg {gets} {(+/{omega}) {div} {rho}{omega}}
>
> The only significant difference here is that the J expression is just a
> normal part of the language (i.e. the result of an operator expression),
> whereas the APL is a special syntax that treats the curly braces as a
> function definition.
>
> J's tacit definitions correspond to APL's operator expressions; there
> are just more of them, and J also includes phrasal forms. Dyalog has
> already done a lot in this area, and presumably could do more.
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
