Roger Hui wrote:
>
> http://www.jsoftware.com/jwiki/Doc/Elementary_Functions_An_Algorithmic_Treatment#evaluation_order
>
> by Ken Iverson, 1966.
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
>
Thank you for this link. My reply comes a bit late since I've read your
message and the text only day before yesterday, and it's about the
"Appendix A: Conventions Governing Order of Evaluations" of Iverson.
The reply is accordingly a bit longer, but I promise to a patient reader
deconstruction of the Appendix, which begins with a concern for
conventions of order of evaluation of unparenthesized
expressions: ("The common conventions for the evaluation of
unparenthesized expressions[...]" p.219), their rules, drawbacks of some
of them and ways to improve on them. The Appendix is to justify the use
of a particular convention: "The one convention used in this book is
that (subject to parenthesis) evaluation proceeds from right to
left. This appendix treats the major reasons for this choice"(p. 219, my
italics).
If the right-to-left convention is merely a convention, and this is both
mathematically true and linguistically emphasized by Iverson, then no
reasons are necessary to be stated other than stating the conventional
nature of this or that particular order of evaluation. The reasons are
necessary only if convention is not convention, if some conventions are
more valuable or useful than others, albeit formally equivalent. A
convention, for instance, can appreciably lose on value when parentheses
are needed due to possible ambiguities in interpretations of some
expressions: "Such expressions would be parenthesized anyway for
clarity; but then the convention seems to lose most of its value." (p.
219). Parenthesis increase the clarity when an ambiguity might arise,
but also, by that same appearance of the parenthesis increasing the
clarity, the convention has gotten its value diminished.
When ambiguities of notations are avoided by a formalization through
operator precedence ("Programming languages [...] have usually treated
the problem by establishing a hierarchy of priorities[...]" p.220), such
a solution has high complexity of convention ("such a system is
usually very complex" p.220). Choosing between parenthesis, guarantying
the proper, stable, universal, unequivocal meaning of the representation
of mathematical expressions in any convention, and a burdening of
programmer with memorization of the hierarchy of a particular
convention, prudence as well as insufficiently stable knowledge of the
given programming language (due to the complexity of its notation) would
eventually make the programmer choose parenthesis: "The occasional (and
the prudent) programmer avoids the whole issue by including all the
parentheses that would have been required with no convention."
(p. 220, italics added).All that programmers would have been doing
therefore is writing in LISP in any programming language that is too
complex to memorize, LISP being the ultimate unequivocal parenthesizing
notation, the no-convention convention, the starting point from which
any convention may be developed (Iverson says: "Any convention
will reduce the need for parentheses,[...]" p.221, italics added). Any
convention will be more efficacious than LISP in using the parentheses
and, by the same incontestable clarity of parenthesizing, more
ambiguous.
Iverson thus desires to have a convention that decreases the number of
parenthesis used, without increasing the complexity of the convention
itself, subject to one unspoken rule: that expressions involve monadic
and dyadic operations. Dyadic operations are now increasing the
complexity of both his and the "standard" mathematical convention with
respect to the canonical, monadic-only parenthesizing (non-)convention
of the maximal clarity and the maximal use of parenthesis.
The convention thus decreases the number of parenthesis but it is more
complicated to learn due to increased complexity: The problem with order
of evaluation is now how to evaluate F G x, and x F y G z (then F G H,
etc). The first one can be like in LISP, with outer parenthesizes
removed as unnecessary since it is about monadic function, F G x === F(G
x), while the second one can be either (x F y) G z, or x F (y G z), and
Iverson argues through 6 examples why the latter should be the better
choice. The results of the convention applied to A Programming Language
and consequently to J are undoubtedly ingenious, as they allow for
writing short, fast and powerful programs. All this provided that
programmer does not find the notation too complex to learn.
--
View this message in context:
http://www.nabble.com/right-to-of-left----what-about-left-to-right--tp18155817s24193p18658193.html
Sent from the J Chat mailing list archive at Nabble.com.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
