Subject: Re: Better Dylan syntax? From: Erik Naggum <clerik@naggum.no> Date: 1997/09/03 Newsgroups: comp.lang.dylan,comp.lang.lisp Message-ID: <3082319867814110@naggum.no> * Gareth McCaughan | But to say, as Erik did, that "infix folks can't hack a < b < c" is just | plain wrong. C and Pascal folks may be unable to hack a<b<c, but that | doesn't have much to do with infixness (infixity? infixitude?). hm. in a < b `<' is a binary operator, while it is ternary in a < b < c, and n-ary in a < b < ... < z. although I know of no language that has anything but binary infix operators, I get the impression from the above that you do. (if not, I will continue to believe that arity _is_ connected to infix vs prefix. in particular, n-ary functions are usually written in a prefix form in infix languages, too, so one might argue that infix vs prefix should only be fought on the grounds of binary operators, but this destroys the motivation for the fight, which was to show that infix was more natural in general. if something is more natural only for extremely restricted parts of what people wish to do, and one can demonstrate that they are, in fact, restricted in their thinking as a result, I think we have a pretty good argument that such restrictions should be lifted, and thus that n-ary operators must be allowed to compete, which would mean that infix must plead nolo contendere and prefix must win.) there is also an important difference between n-ary infix operators (if they do exist) that basically expand to a long sequence of binary operators with `and' glue in between, the glue itself being binary in nature (plus some guarantees about one-time evaluation of duplicated terms), and true multi-argument functions, as is the natural thing in prefix syntax, such as for ordering in particular. to a Lisper, (< a b c) probably communicates "monotonically increasing order of" instead of "less than". at least it does to me, and I find similar ways to "read" the prefix form vastly more expressive and easy to deal with. e.g., (first foo) is read as if it were "first of foo". (it is, of course, no more read out loud than any other reading is.) I also find it interesting to see how ranges are expressed in the integer subtypes. a inclusive range like [0,10] would be written (integer 0 10), but an exclusive range like (0,10) would be written (integer (0) (10)), so one would be tempted to define new _types_ for specific ranges and use, say, (check-type x state-index) where state-index might be (integer 0 31), instead of an explicit test like (<= 0 x 31). what does this have to do with infix vs prefix? I'm trying to show where prefix _gains_ a user above being a mechanical rewrite of the infix forms, showing a more mathematical thinking than the simple, syntactic arithmetic forms that infix favors. I believe infix syntax restricts us to think about that which can be expressed with binary operators and that it would actually be _relieving_ to be able to work with n-ary operators in practice, without incurring a high syntactic cost. (I know ML can use infix syntax for user-defined functions, too, but there are other factors that make ML's syntax less bothersome than the infix syntax as found in Pascal, C/C++, Perl, etc.) #\Erik -- 404 You're better off without that file. Trust me.