The need for C.A.T.S.U.P. lives on!
It's time to repost the following, with no hard feelings towards the participants in the current discussion about the never-ending sense of wonder and astonishment that Haskell's concrete syntax inspires in even the most jaded programmer. Brought to you by Haskell, a founding member language of the League for Avoiding Waste in Character Set Usage. Our motto: a meaning for every squiggle, and two squiggles for every meaning! [Originally transmitted 13 March 1991] :-) Are you tired of your precious mail-reading time being usurped for the nitpicking discussion of Haskell operator precedence minutiae? :-) Are you itching to get back to the careful study of the design and implementation of programming language CAPABILITIES? :-) Are you concerned that this debilitating disunity among the prophets of the TRUE FUNCTIONAL RELIGION may be the work of agents-provocateurs in the service of the EVIL IMPERATIVE EMPIRE? :-) Then don't just sit there passively--join C.A.T.S.U.P., the Committee Advocating The Superstitious Use of Parentheses! :-) C.A.T.S.U.P. is a new political action coalition being convened around a nucleus of Old Lisp Hands, Moderate Pragmatists, and Abstract Thinkers Who Are Above Thinking About Concrete Syntax. C.A.T.S.U.P.'s objective is to restore the functional programming community to full research productivity by advocating the adoption of the following credo: :-) Inference Rule 1) If you can't remember the operator precedence, Then put in some extra parentheses. :-) Inference Rule 2) If you thought you had the precedence right, but the computation did not proceed as expected, Then put in some extra parentheses and try again. :-) Axiom A) Nobody remembers operator precedences. :-) Lemma: Some extra parentheses will be put in, no matter how carefully the operator precedence is designed (provided, of course, that some infix operators are used at all). Proof: Immediate from Axiom A and Inference Rule 1. :-) -- -- Dan Rabin, Old Lisp Hand, Moderate Pragmatist, and Abstract-Thinker-Who's-Above-Thinking-About-Concrete-Syntax-in-training.
Re: relative precedence of ! and function application
Please take me off this mailing list. I no longer have time to read it. Thank you, greg Greg Sylvain Hughes/STX Internet (arpa): [EMAIL PROTECTED] Programmer/Analysts Phone : 301 - 513 - 1622 Remember: 90% of everything is dealing with the brain-damaged.
Re: relative precedence of ! and function application
->Given that layout has been used in Miranda, Haskell, etc., to determine ->when one thing ends and another begins, it might be worth trying the ->same idea within expressions. The suggestion is that any subexpression ->that contains no white space but is surrounded by white space has ->implied parentheses around it. Hence -> f x!i ->would parse as -> f (x!i) -> I think this would be a _big_ mistake. Using layout to provide grouping in a language should be _very_ carefully. Using indentation to provide grouping is a good idea, because it's very easy to see the grouping for a reader - much easier than it would be with symbols providing the groups. But to make the insertion of a space in an expression so significant, I think is a very bad idea. It's not clear looking at an expression what the grouping is, if spaces create implied parens. The extra verbosity of the parens is necessary for the human reader. || Mark Craig Carroll: ||"In all seriousness of truth, hear this: || Univ of Delaware, Dept of CIS|| without the It, one cannot live. But || Grad Student/Labstaff Hacker || whoever lives with It alone is not || [EMAIL PROTECTED] || human" - _I_and_Thou_, by Martin Buber
Re: relative precedence of ! and function application
|Given that layout has been used in Miranda, Haskell, etc., to determine |when one thing ends and another begins, it might be worth trying the |same idea within expressions. The suggestion is that any subexpression |that contains no white space but is surrounded by white space has |implied parentheses around it. Hence | |f x!i would parse as f (x!i) | |This would make functions definitions with pattern matching easier too. |For example, we could write: | |sum x:xs = x + sum xs | |instead of | |sum (x:xs) = x + sum xs | |I'm not completely convinced myself, but thought it was an idea worth |floating. | |Warren Mark Wells reported, in a paper in SIGPLAN Notices a few years ago, using a similar scheme in the language Modcap. (A funny thing about this paper is that he attributes the idea to me, and I don't recall suggesting any such thing!) In, Modcap, I believe, the notion was that white space surrounding an operator modified its syntactic precedence, so that an operator with space around it had a lower precedence than any without space. Mark also noted that the scheme could be extended to allow larger amounts of white space to imply yet lower precedence levels, but they didn't implement this extension and weren't convinced of its benefits. Frankly, the idea frightens me (which is why I was a bit perturbed at having it attributed to me :-), but Warren has a good point about its being consistent with layout. By the way, Mark reported that their experience with this trick was quite positive. --Joe
Re: relative precedence of ! and function application
Given that layout has been used in Miranda, Haskell, etc., to determine when one thing ends and another begins, it might be worth trying the same idea within expressions. The suggestion is that any subexpression that contains no white space but is surrounded by white space has implied parentheses around it. Hence f x!i would parse as f (x!i) This would make functions definitions with pattern matching easier too. For example, we could write: sum x:xs = x + sum xs instead of sum (x:xs) = x + sum xs I'm not completely convinced myself, but thought it was an idea worth floating. Warren
