Re: relative precedence of ! and function application

1992-08-07 Thread Warren Burton

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




Re: relative precedence of ! and function application

1992-08-07 Thread Gregory Sylvain

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

1992-08-07 Thread jhf

|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

1992-08-07 Thread Mark C. Carroll


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

1992-08-07 Thread Dan Rabin

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.