From ...
From: Erik Naggum <clerik@naggum.no>
Subject: Re: Better Dylan syntax?
Date: 1997/09/03
Message-ID: <3082319867814110@naggum.no>#1/1
X-Deja-AN: 269796832
References: <comp.lang.dylan.199708151441.PAA09067@gairsay.aiai.ed.ac.uk> 	<comp.lang.dylan.mail2news.22171.15.08.97.17.32.38@harlequin.co.uk> 	<5u5826$s5v$1@sparky.franz.com> 	<MPG.e70b527558ec90f989a07@news.demon.co.uk> 	<3407180B.E0D@lavielle.com> 	<MPG.e71df6cc101b8c7989a0c@news.demon.co.uk> 	<3081955196009454@naggum.no> 	<MPG.e737799702befd5989a16@news.demon.co.uk> 	<y8a2038aotb.fsf@horten.artcom.de> <873212194.23826@dejanews.com> 	<y8apvqrk6as.fsf@horten.artcom.de> <3082226718813462@naggum.no> 	<86lo1ecxxo.fsf@g.pet.cam.ac.uk> <y2hbu2alcl4.fsf@esat.kuleuven.ac.be> <86bu2acqpi.fsf@g.pet.cam.ac.uk>
mail-copies-to: never
Organization: Naggum Software; +47 8800 8879; http://www.naggum.no
Newsgroups: comp.lang.dylan,comp.lang.lisp


* 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.