### 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

sum (x:xs) = x + sum xs

I'm not completely convinced myself, but thought it was an idea worth
floating.

Warren

```

### Re: relative precedence of ! and function application

```
Please take me off this mailing list.  I no longer have time to

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)
|
|This would make functions definitions with pattern matching easier too.
|For example, we could write:
|
|sum x:xs = x + sum xs
|
|
|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)
-

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.

MC

|| Mark Craig Carroll: MC ||"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

```

### 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

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