William Paul Vrotney wrote: > [...] Popular acceptability is a persistent force. After > Arabic numerals were introduced it took society using Roman > numerals hundreds of years before it accepted Arabic numerals.
And we still write them backwards. (That is, since we write english from left to right, we should be writing numbers least-significant digit first from left to right.)
* Andreas Bogk | Maybe it's just that I've been using infix syntax ever since I've learnt | it in school by the age of 7. Maybe it's because I've never had a UPN | pocket calculator.
I wonder how many Lisp programmers like RPN calculators compared to the rest of the population. (I don't leave home without my HP48GX, and I've used HP calculators since a friend of my father's showed me his when I was only an egg.)
| But | | a[7] := 3; | | is just closer to how I think than | | (aref-setter 'a 7 3) ; and I'm not even sure if this is correct | ; because the syntax gives me so few hints on | ; what is what
you know, a significant part of the problem with non-Lispers not liking Lisp is that they invent such horrible "Lisp" when they don't know what it would actually look like. I think this is indicative of something.
your a[7] is (aref a 7) in Common Lisp. your a[7] := x is (setf (aref a 7) x) in Common Lisp.
depending on how your multidimensional tables look, if you have any, we have a[7][6][5] or a[7,6,5] vs (aref a 7 6 5).
| b := c * d + e * f; | | feels much more natural to me than | | (setq b (+ (* c d) (* e f))) . | | Of course I do understand both forms, but by cultural bias I prefer | infix. In fact, most people do.
for trivial examples, most people do. I find it odd that mostly trivial examples are shown to debunk prefix syntax.
a + b + c (+ a b c) a + b * 4 + c * 16 (+ a (* b 4) (* c 16)) a * (b + 4) * (c + 16) (* a (+ b 4) (+ c 16))
a < b AND b < c (< a b c) a /= b AND b /= c AND a =/ c (/= a b c)
it is also typical of infix languages to run into a terrible mess with the precedence of operators that cause programmers to use temporary variables in order to simplify their expressions to be readable. also, multiline expressions are actually frowned upon in classes because infix just gets too complex. it is not uncommon to find Lisp code that adds together a bunch of values taken from nested expressions in a single form:
(+ (foo 17) (bar 47 11) (zot 23 69))
| And if I gain nothing but a steep learning curve by switching to | prefix, why should I?
you do in fact gain very much. it is just hard for infix people to imagine that prefix forms could yield more than a trivial rewrite of _their_ forms of expression. you won't find Lisp programmers who write (+ (+ a b) c) just because a + b + c is really (a + b) + c, and (and (< a b) (< b c)) is really uncommon in Lisp code even though infix folks can't hack a < b < c, although that's precisely what they learned in their early years in school.
incidentally, reader macros are available that take infix expressions enclosed in some special syntax (like a pair of brackets) and turn them into prefix form for Lisp to see. this only works for trivial arithmetic.
#\Erik -- 404 You're better off without that file. Trust me.
* Martin Rodgers | I've just been speaking to Erik by phone, and he tried the same | tactic. Unfortunately, I indulged him, and then we ran out of time. I | was hoping to dicuss syntax etc, but no matter. There's very little | worth saying, really. After all, it has already been said. | | As for Erik's flaming...We didn't have time to discuss that, either.
you know, for a person who professes not to talk about people but about so and so random and irrelevant issue, you have a bizarre hangup with discussing those people who _reject_ your pathetic attempts at "contact".
the first thing I told you in your unsolicted, unwanted phone call was that it wasn't a good time to call because I had a friend coming over and had to clean up a little first. I had to tell you that I had to hang up because of my invited guest _five_times_ and you still kept talking and talking and I had no option but to hang up on you. I keep the phone number in the Organization header and on my home page and stuff like that because I want to give people I'd like to talk to a chance to reach me. I do _not_ keep it there to invite stalkers and pathetic wannabes a chance to annoy me.
I also seem to remember you telling me that you had lots of people who agreed with you and me encouraging you to talk to them instead of bothering _me_ all the time.
and we didn't run out of time, you pathetic liar, _you_ had no time to run out of to begin with since you were going on overtime from the very start. yes, I have blocked your e-mail with the same software that blocks equally undesired unsolicited commercial e-mail, but you keep mailing me from other addresses, flat out refusing to take a hint. how many ways and how many times do I need to tell you that I DO NOT WANT TO COMMUNICATE WITH YOU. I thought I had made this exceptionally clear, but when I don't want to talk to you, you take this public with despicable lies about what you did. this is _unbelievably_ tasteless. I cannot fathom what you think you can gain from me that you want so badly as to attempt to extort it from me with this abominable form of blackmail that you engage in.
GO AWAY, Martin Rodgers!
#\Erik -- 404 You're better off without that file. Trust me.
Aaron Gross wrote: > Why should we be writing numbers least-significant digit first? > This makes you skip ahead to get to the important part. [...]
Arabic is written from right to left (isn't it?), which is why Arabic numbers are written right to left least significant digit first. Think about doing math with natural numbers; everything starts with the least significant digits at the right and extends to the left.
Just trying to figure out how culturally sticky syntax can be.
Maurizio Vitale wrote: > That wasn't the point. Erik's point (at least as I understood it) was > that most non-lisp programmers when faced with a lisp-in-3-days kind > of introductions are tempted into writing
> (and (< a b) (< b c))
> simply because they think in the language they come from and simply > map && into and, < into < and switch from infix to prefix.
I'm sure that's true, but it's a point about the specific languages they're coming from rather than about infix notation as such.
If there were a lot of people saying "look how ugly prefix notation is -- you have to write (and (< a b) (< b c))", then it would be very relevant to point out that you don't. But the usual objection is "simple arithmetic expressions are much more cumbersome", and to that it simply isn't relevant that some languages using infix notation are unnecessarily ugly too.
What's more, infix notation can lead to winnage here too; you can (in principle) say things like "a<b<=c/=d", which *would* have to be represented by a big "and" in Lisp.
Erik's main argument for prefix notation (it's regular and copes better than infix with complicated stuff) is absolutely right, and when combined with the facts that
- prefix notation is much nicer for machines to work with, making e.g. clever macros easier to write
- prefix notation is exactly what just about all languages use for function calls, so that the alleged advantages of infix notation only apply to a very limited class of expressions
it's a good argument. 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?).
-- Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics, gj...@dpmms.cam.ac.uk Cambridge University, England.
* 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.
> William Paul Vrotney (vrot...@netcom.com) wrote: > : > : [some points in favor of Common Lisp syntax] > : > I have tried recently Scheme, and the "simplicity of the syntax" that > is sometimes pointed is not an obvious advantage in my opinion.
> The code I wrote was cluttered with things like:
If I had to do this by addressing individual array elements. Most of the time code like this occurs while iterating over array elements, which I would do using a mapping function; see below.
> And there was many instances things like:
> (let ((result 0)) ; MIT scheme doesn't allow (define result 0) :-(
Hmm. It doesn't? Doesn't Scheme allow globals? Anyway, the let structure is better from a software engineering standpoint; if you learn to program without relying on side-effects you'll be amazed at how much easier your code is to debug.
Shorter and (once you're comfortable with the anonymous function syntax in CL, which I admit could stand improvement) clearer.
> It looked somewhat like Tcl-programming to me (except that scheme is much > more fun) and I still prefer Python syntax. Until at least I become > enlightened about the wonderful scheme macros (it seems easier to find PhD > thesis than tutorials on this topic). Of course, I tried to switch to > Common Lisp, but, well, I'm still reading CLTL :-)
CLTL is a good reference but a lousy way to learn CL. I'd recommend Paul Graham's 'ANSI Common Lisp'. It has a good introduction to CL macros, and the same author's 'On Lisp' treats the subject in depth. CL macros differ from Scheme macros but are at least as powerful. For example, a library in the CMU archive contains the macro 'doseq' with the aid of which our second example could have been written:
> For now, I can courageouly cope with the internal complexity of > parsers/software tools of other languages (especially since I don't write > them). Your mileage varies.
Well, once you've worked with a language that makes it easy for you to write them, it's hard to go back.
> BTW it's not fair to compare Lisp syntax exclusively to C++. There are > other languages with syntaxes less clumsy than the latter.
Sure, but Python isn't suitable for real applications. Too slow, and the use of indentation as a control flow construct makes it unsuitable for writing anything that has to be maintained over a long period of time. It makes a nice scripting language, though. Of course, Python isn't the only other contender, so your point stands.
Erik Naggum <cle...@naggum.no> writes: > * 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.
There're language with infix N-ary operators (Including C with ? :). I'm also sure there're languages with user-definable infix N-ary operators but those are much rare and I cannot give a name off hands, but I'll look it up. There was a paper (by S.P.Jones of Haskell memory) about parsing those languages, but none of the languages I know in that class (KRC, Miranda and Haskell) allows user defined N-ary operator.
In some sense message sending in Smalltalk could qualify, as you write things like object :selector1 val1 :selector2 val2, but that's stretching the definition a bit.
Maybe someone else can help my memory (Snobol4 or Icon?)
Bruce Tobin <bto...@infinet.com> writes: > Sure, but Python isn't suitable for real applications. Too slow, and > the use of indentation as a control flow construct makes it unsuitable > for writing anything that has to be maintained over a long period of > time. It makes a nice scripting language, though. Of course, Python > isn't the only other contender, so your point stands.
sheesh. I thought your post was pretty reasonable until I read this bunk. I have no idea what you mean by "real applications," but what you wrote sounds suspiciously like flame-bait. I once wrote a 2000 line application in Python; (took me about 2 weeks) it felt pretty real to me. (you may be talking about 100,000 line apps, but how many apps get that big?) As for the speed issue, Python is like any other language: you write your code, and if performance is a problem, you optimize (and in python, you can optimize like crazy by rewriting time-critical parts in C). And stop making wild, unsupported claims like the one about indentation-based syntax ruining maintainability. What are you talking about? The only reason Python's syntax is like that is to _improve_ readability and hence, maintainability. And that is just what it does.
I don't mean to bite your head off, but what do you expect when you insult a language so near and dear to my heart?
-Lyn
------------------------------------------------------- remove the word "bogus" from my address for the real one.
In article <862035xpyn....@g.pet.cam.ac.uk>, Gareth McCaughan <gj...@dpmms.cam.ac.uk> wrote:
> - infix languages encourage a possibly misleading distinction > between built-in binary operations and user-defined functions;
I don't think this is quite the distinction they make. Rather, the distinction is between "common arithmetic and similar operations" and "other operations", since many infix languages have built-in operations that use function call notation (PL/I and Fortran have quite a few), and some infix languages allow user-defined functions with infix notation (e.g. C++'s operator overloading).
> - infix languages accordingly tend to make their builtins binary > when they could, with different syntax, be variable-arity;
True. Luckily, some of he most common infix operators, such as + and *, also happen to be associative and commutative, so they act like they're variable-arity.
> - infix languages are less easily parsed;
This is an issue for quick and dirty code, but it's not an issue for implementors -- compiler technology to parse infix notation is quite mature.
-- Barry Margolin, bar...@bbnplanet.com GTE Internetworking, Powered by BBN, Cambridge, MA Support the anti-spam movement; see <http://www.cauce.org/> Please don't send technical questions directly to me, post them to newsgroups.
> In article <862035xpyn....@g.pet.cam.ac.uk>, > Gareth McCaughan <gj...@dpmms.cam.ac.uk> wrote:
> > - infix languages are less easily parsed;
> This is an issue for quick and dirty code, but it's not an issue for > implementors -- compiler technology to parse infix notation is quite > mature.
The fact "infix languages are less easily parsed" applies to programmers as well as compilers. I can't count the number of times I've wasted lots of time on bugs in C and C++ expressions because of an oversight "infixing" the precedence rules. This never happens in Lisp.
Funny thing is, I've noticed that to save time many C and C++ programmers (and I'm guilty myself) will put in a lot of parentheses to avoid spending the time to parse the expression and to be sure of the outcome.
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes: >To appreciate Lisp syntax, it helps to appreciate that the syntax is >for data, and that Lisp data can be used to represent Lisp code. This >simple idea isn't as obvious to everyone. This could be one of the >major causes of confusion about Lisp, and so hostilty toward Lisp.
I'd like to toss in a word here: Prolog. Prolog and Lisp have a heck of a lot in common. In particular, they share the idea that "to read code" is the same thing as "to read data". Just as you can read a function OR a data value in Lisp by calling (read), you can read a clause OR a data value in Prolog by calling read(Result). Prolog allows user-defined prefix, infix, and postfix operators in input _and_ output. These don't get in the way of macro processing, because it's defined that X + Y is just sugar for +(X,Y). Some Prolog systems have supported distfix operators as well, so that e.g. if X then Y else Z ==> 'if then else'(X, Y, Z).
There are quite a number of things that Lisp reader-macros deal with that have no Prolog equivalent (like ' and #'), but I don't see any particular reason they couldn't be supported as well.
-- Unsolicited commercial E-mail to this account is prohibited; see section 76E of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation Amendment Act No 108 of 1989. Maximum penalty: 10 years in gaol. Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
> > Sure, but Python isn't suitable for real applications. Too slow, and > > the use of indentation as a control flow construct makes it unsuitable > > for writing anything that has to be maintained over a long period of > > time.
> sheesh. I thought your post was pretty reasonable
At least if you ignore the lisp code not working.
> until I read this > bunk. I have no idea what you mean by "real applications," but what > you wrote sounds suspiciously like flame-bait.
Poor choice of words on my part. What I meant to say is that Python is not yet suitable for medium-to-large scale application development. Of course, lots of folks would disagree with even this modified statement, but I'm prepared to defend it.
> I once wrote a 2000 > line application in Python; (took me about 2 weeks) it felt pretty > real to me. (you may be talking about 100,000 line apps, but how many > apps get that big?)
Well, many of the apps I work on get that big. Too many of them, unfortunately. Of course, some of those who read the code in my last post may feel compelled to observe that if I wrote code more correctly I might not need to write so much of it.
> As for the speed issue, Python is like any other > language: you write your code, and if performance is a problem, you > optimize (and in python, you can optimize like crazy by rewriting > time-critical parts in C).
Sometimes that's feasible, and sometimes not. Contrary to accepted wisdom on this subject I've found that paying a little attention to performance issues from the outset can save you a lot of grief later on; YMMV.
And stop making wild, unsupported claims
> like the one about indentation-based syntax ruining maintainability. > What are you talking about? The only reason Python's syntax is like > that is to _improve_ readability and hence, maintainability. And that > is just what it does.
There are just too many ways that indentation information can disappear from code that has to be maintained over a long period of time by many different people: sections of code get cut and pasted, editors convert spaces to tabs and disagree as to how many spaces a tab should expand into, etc. People (and tools) are used to treating whitespace as meaningless.
> I don't mean to bite your head off, but what do you expect when > you insult a language so near and dear to my heart?
I'm just relieved that you saw fit to ignore my lousy code.
Indeed. I probably only prefer Lisp's syntax to Prolog's because I have less experience with Prolog. Yet every Prolog tutorial that I found in magazines left me bewildered. It was only when I started reading tutorial _books_ that I finally "got it". It was one of Prolog's features that I now appreciate most that used to confuse me the most: the ability to write goals like "not(X)". A definition of 'not' would've clarified the meaning for me!
It illustrates how easy it is for someone used to one kind of semantics to be confused by a language that uses a similar syntax with totally different semantics. The goal "not(X)" doesn't find the value of X and then apply 'not' to it. It isn't the same as a function that negates a boolean value, which is how someone unfamiliar with Prolog might read it.
Still, for me that confusion only lasted a short time, and didn't do any harm. In fact, it made me even more curious about Prolog!
I agree about ' and #'. If you want them badly enough, then you could write your own Prolog parser and add them to it. Perhaps this has already been done? I've certainly seen examples that looked like extentions to Prolog's syntax.
Are there any other languages we could mention? ;-) -- <URL:http://www.wildcard.demon.co.uk/> You can never browse enough Please note: my email address is gubbish ignorance is better than stupidity you can cure ignorance
Cedric Adjih wrote in article <5u6og8$...@news-rocq.inria.fr>...
> Ok, I grant you that in that case semantics won't map trivially to >syntax (i.e. code would be unreadable). But that's a problem that I >have with scheme. The code I wrote was cluttered with things like:
>while in Python that would be written: > container.content[i]=container.content[i]+someData[i]
Without some surrounding context, I can't be sure what you were doing, but having code that is ``cluttered'' with certain types of expressions usually means that there is some abstraction that could be expressed. For example, if you are performing an elementwise computation on vectors, perhaps code along the lines of this would be what you want:
(vector-add! (mytype->content container) some-data) for some suitable definition of vector-add! (With the usual caveats about destructive operations, of course).
>And there was many instances things like:
> (let ((result 0)) ; MIT scheme doesn't allow (define result 0) :-( > (do ((index 0 (1+ i)) > ((= index (vector-length (mytype->field myinstance))))) > (let ((field1 (vector-ref (mytype->field myinstance) i)) > ...))) > OR > (do ((index 0 (1+ index)) > (result 0)) > ((= index (vector-length (mytype->field myinstance))) result) > (let ((field1 (vector-ref (mytype->field myinstance) index)) > ...)))
again, you might want to define and use a vector-mapping procedure: (define (vector-map f v) (do ((index 0 (1+ index))) ((= index (vector-length v))) (f (vector-ref v index))))
(and once again, I'm ignoring the result variable that must have been mutated.)
The point being, if you have duplicated code, wrap it up in a function and pass in the varying code with a lambda expression. I'll grant you that it does take a little getting used to.
In article <5uqln2$ho...@newsie2.cent.net> "ET" <emerg...@eval-apply.com> writes:
From: "ET" <emerg...@eval-apply.com> Newsgroups: comp.lang.dylan,comp.lang.lisp Date: Sat, 6 Sep 1997 00:22:11 -0400 Organization: CENTnet, Inc. Lines: 61 NNTP-Posting-Host: tsa-139.cape.com X-Newsreader: Microsoft Outlook Express 4.71.1008.3 X-MimeOle: Produced By Microsoft MimeOLE Engine V4.71.1008.3 Xref: agate comp.lang.dylan:8456 comp.lang.lisp:30556
Cedric Adjih wrote in article <5u6og8$...@news-rocq.inria.fr>...
> Ok, I grant you that in that case semantics won't map trivially to >syntax (i.e. code would be unreadable). But that's a problem that I >have with scheme. The code I wrote was cluttered with things like: > > (vector-set! (mytype->content container) i > (+ (vector-ref (mytype->content container) i) > (vector-ref some-data i))) > >while in Python that would be written: > container.content[i]=container.content[i]+someData[i] >
Just to be fussy, in Common Lisp (using M. Kantrowitz's INFIX package) you can write
#I(content(container)[i] += someData[i])
Cheers -- Marco Antoniotti =========================================================================== === California Path Program - UC Berkeley Richmond Field Station tel. +1 - 510 - 231 9472
In article <34079235....@interaccess.com>, joe davison <j...@interaccess.com> wrote:
>The answer to that is what most lispers fail to mention. Humans >are not the only ones who read lisp programs.
This is very true. For all its faults, I learned to appreciate Lisp syntax the first time I debugged a function by evaluating its sub-expressions by hand in MIT Scheme's editor. One day I was doing "type, save, compile, link, execute" and the next day "type, execute, type execute, save (when it works)". I haven't yet found an editor for an infix language that can do that. (I'm not talking about a REPL, but an editor)
I'm not convinced that the benefit of this feature overwhelms the cost in education and popularity, but I can see how it is addictive.
In article <vrotneyEG0o2w....@netcom.com>, William Paul Vrotney <vrot...@netcom.com> wrote:
>Funny thing is, I've noticed that to save time many C and C++ programmers >(and I'm guilty myself) will put in a lot of parentheses to avoid spending >the time to parse the expression and to be sure of the outcome.
Why is this something to be guilty of? If parenthesis make the expression easier to understand then putting them in is a good thing, right?
>>>>> "William" == William Paul Vrotney <vrot...@netcom.com> writes:
William> The fact "infix languages are less easily parsed" applies William> to programmers as well as compilers. I can't count the William> number of times I've wasted lots of time on bugs in C and William> C++ expressions because of an oversight "infixing" the William> precedence rules. This never happens in Lisp.
C precedences are broken. Even more so since C involves lots of pointer arithmetics. And C++ has this stupid notation of using << and
>> for input and output.
Andreas
-- Never underestimate the value of fprintf() for debugging purposes.
> I'm not convinced that the benefit of this feature overwhelms the cost in > education and popularity, but I can see how it is addictive.
Perhaps the cost is that we may alienate some programmers. It may just be a question of _which_ programmers: those who choose prefix before anything else, or those who choose infix before anything else.
I know what you mean about the addictiveness. Of course, these days we can just hit buttons on a toolbar, instead of typing, but the principles are the same - as long as you do actually have a toolbar.
Yep, I'm a point and click addict. ;) -- <URL:http://www.wildcard.demon.co.uk/> You can never browse enough Please note: my email address is gubbish ignorance is better than stupidity you can cure ignorance
In article <86wwkvn5ol....@g.pet.cam.ac.uk>, Gareth McCaughan <gj...@dpmms.cam.ac.uk> wrote:
>I'm not sure I agree. I'm thinking not of compiler writers but of >ordinary programmers writing macros and other such things. That >happens all the time, unlike compiler writing which doesn't need >to be done from scratch too often, so it's not enough for the >technology to be mature -- it's better if it's pretty easy too.
It's a little redundant to write a parser anyhow. Maybe it would be better if the compiler's parser were provided as a library that you could use from your favourite macro language. This is, for example, how people typically work with SGML -- through an API or pre-parsed "pablum" form. It seems to work, but people still complain that parsing SGML is too hard so obviously they want to write their own parsers for whatever reason (habit?).
> Why is this something to be guilty of? If parenthesis make the expression > easier to understand then putting them in is a good thing, right?
That's why I've always done it! That, and my discomfort with infix. If it helps me write code that I know will be be compiled correctly, with the meaning that I intended, then I won't feel guilty about it.
Maybe this helped me accept Lisp's syntax...No parenthesis phobia, but a very strong aversion to infix. This "parenthesis guilt" is for those people with a parenthesis aversion. It's probably made worse by the use of editors unable to do parenthesis matching. Strangely, I can cope without parenthesis even when using Lisp, but I appreciate it in almost _any_ language. (One obvious except would be Forth.)
My motto could've once been "Give me parentheses or syntax errors". ;) -- <URL:http://www.wildcard.demon.co.uk/> You can never browse enough Please note: my email address is gubbish ignorance is better than stupidity you can cure ignorance
C precedences are broken. Even more so since C involves lots of pointer arithmetics. And C++ has this stupid notation of using << and >> for input and output.
C/C++ precedence are not that broken. They are just very complex, due to the fact that practically every character in C/C++ has a meaning as an operator.
In passing, I'd say that one of the nicest things of C++ are the << >> stream operators. You can write pretty sophisticated and elegant code with them.
-- Marco Antoniotti =========================================================================== === California Path Program - UC Berkeley Richmond Field Station tel. +1 - 510 - 231 9472
Barry Margolin wrote: > Gareth McCaughan <gj...@dpmms.cam.ac.uk> wrote: > > - infix languages are less easily parsed;
> This is an issue for quick and dirty code, but it's not an issue for > implementors -- compiler technology to parse infix notation is quite > mature.
This might be true. It is true, of course, if you know all your infix operators when you build your parser/parse tables. But I do not know how to handle the situation where you
- have user-defined infixes _and_ - you want/need to use tools like bison/yacc/zebu ...
Is there something I should know and obviously don't?
Thanks, Axel
-- === Axel Schairer, htt p://www .df ki.de/v se/staf f/sch airer/ === [So long as you predefine a parser rule for each precedence level, it's not hard to fiddle the lexer to return user-defined operators as op tokens at the appropriate level. -John] -- Send compilers articles to compil...@iecc.com, meta-mail to compilers-requ...@iecc.com.
* Paul Prescod | It's a little redundant to write a parser anyhow. Maybe it would be | better if the compiler's parser were provided as a library that you could | use from your favourite macro language. This is, for example, how people | typically work with SGML -- through an API or pre-parsed "pablum" | form. It seems to work, but people still complain that parsing SGML is | too hard so obviously they want to write their own parsers for whatever | reason (habit?).
there is no agreement on what an SGML document "means", and widely varying ideas about what should and should not be _unavailable_ after the parsing has completed. this means people _will_ want to handle the raw text form of SGML as opposed to some arbitrarily chosen non-textual form. there is some consensus in the SGML community that two SGML documents are the same only if their textual forms are bitwise identical. there are many attempts to use _comments_ for various half-witted purposes, and comments are typically ignored in the parsed forms. etc.
had SGML defined a "read syntax" and talked about objects at a post-parse level, SGML would have been a lot more interesting. in SGML today, every whitespace is sacred, every inferred delimiter must be marked as not present in the text, etc. you just can't handle this mess intelligently by defining a _single_ "API", and you will always find people who are smarter than the last guy who defined a "complete API". it's sad, really.
#\Erik -- 404 You're better off without that file. Trust me.
