Thanks for engaging, and thanks for thinking about it. While a great deal of sentences that use parentheses could be rewritten and reordered not to, we often think out a solution in a certain order of operation, and parentheses lets us implement the order we considered most natural. Unless you are arguing that parentheses should be removed from the language, then a clearer way to group parameters, if it exists is a good thing too.
if 1-~4 2+/ . * 3 3 is equivalent to the 5-level parenthesis expression I used as an example doesn't change the fact that it would require reflection from experts to produce the equivalent form, and deleting one parenthesis and adding another, probably requires the above expression completely from scratch changing the number of operators. While on the topic, it would be nice if the . operator on the vocabulary page offered a mini refresher course in matrix algebra In addition to clearer intent, and easier reading writing and editing of code, as justification for a more flexible parentheses system, I do feel that a common mistake I and others used to other parsing orders, and used to writting equality tests one way, consistently make: if. 2|x = 0 do. f end. while easily fixed by wording the sentence as if. 0=2|x do. f end., doesn't change the fact that the code comes out of my head the first way... and when I eventually catch the error, will end up looking like (2|x) = 0. I don't think the space character is hard to parse. multiple spaces will not have any impact. Even the "crazy people" using proportional fonts can make them out between tokens. A space between all tokens and no space between any tokens will parse to the same sentence. I'll come up with a translator function in a couple of days. It doesn't look complicated, but I'm learning sequential machines first, because that might simplify implementing the solution further. --- Devon McCormick <[EMAIL PROTECTED]> wrote: > Though I initially mis-interpreted this thread as an > argument for a > throwback > to order-of-operation parsing, now that I better > understand it, I remain > unconvinced > this proposal's usefulness outweighs its > complication. > > Consider that the original example would be better > written in a more J-like > fashion, without parens, like this: > > 1-~4 2+/ . * 3 3 > > (assuming the two "3"s only accidently have the same > value and avoiding the > special decrement function "<:" on the same > assumption for "1".) > > It's hard to abstract from one simple, scalar, > example like > this to understand the advantage of changing the > parsing order, > especially one which places such heavy syntactic > lifting on > an invisible character. > > This reminds me of a lecture on C++ by Bjarne > Stroustrup I attended a few > years ago. > I ran into a friend from the APL community there and > we sat next to each > other. Bjarne > began talking about the advantages of overloading > certain symbols. When he > started > showing examples where he was overloading the " " > (space) operator, my > friend and > I both looked at each other in amusement as we > simultaneously realized that > the > date was April 1st and Bjarne was having us on. > > But it's a little too early for that to be the case > here. > > Devon > > On 3/23/06, p j <[EMAIL PROTECTED]> wrote: > > > > I assume that was directed to me. > > > > Many of you will somehow ignore the next sentence, > or > > disbelieve my sincerity regarding it. I fully > > understand the reason and practicality for right > to > > left parsing in J, and have no desire to change > it. > > > > Having the ability to override the default parsing > > order is an undisputed good thing. Working with > > parens is usually a needlessly complicated way to > > override that parsing order. The proposal is to > allow > > the programmer to use a single token ' ' in > situations > > that currently require 2 matching '()'. Its hoped > > that the option makes code clearer and easier to > read > > write and edit. > > > ... > -- > Devon McCormick > ^me^ at acm. > org is my > preferred e-mail > ---------------------------------------------------------------------- > For information about J forums see > http://www.jsoftware.com/forums.htm > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
