RE: Nested pattern binding translates to outermost binding?

2007-07-09 Thread Simon Peyton-Jones
In the section Changes to the Report of the Wiki page you refer to
http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns
I attempted to give the semantics of bang-patterns by saying what changes would 
be needed in the Haskell Report.  If you think it's incomplete or ambiguous, 
then do yell.

(The wiki says that the changes are incomplete but I can't now think why!)

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan
| Weston
| Sent: 06 July 2007 20:08
| To: Haskell Prime
| Subject: Nested pattern binding translates to outermost binding?
|
|  From Haskell' ticket #76:
| http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns
|
|   The main idea is to add a single new production to the syntax
|   of patterns
|pat ::= !pat
|
| Experiments (ghci -fbang-patterns -O2 -S, rename identifiers, then diff)
| shows that nested pattern bindings are equivalent to the outermost binding:
|
| !(!pat)  ==  !pat
| !(~pat)  ==  !pat
|
| ~(~pat)  ==  ~pat
| ~(!pat)  ==  ~pat
|
| but I do not see any wording to that effect either in the Haskell 98
| report, the GHC documentation, or the Haskell' wiki. Have I overlooked
| it, or does it follow from the existing language definition?
|
| Dan
|
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: [Haskell-cafe] Haskell's prefix exprs

2007-07-09 Thread Stefan O'Rear
On Mon, Jul 09, 2007 at 03:55:52PM +0200, Christian Maeder wrote:
 Hi,

 I would like haskell to accept the following (currently illegal)
 expressions as syntactically valid prefix applications:

 f = id \ _ - []
 g = id let x = [] in x
 h = id case [] of [] - []
 i = id do []
 j = id if True then [] else []

 The rational is that expressions starting with a keyword should extend
 as far as possible (to the right and over several lines within their
 layout).

 In this case the above right hand sides (rhs) are unique juxtapositions
 of two expressions. (This extension should of course apply to more than
 two expressions, i. e. f a do [])

 Furthermore the above rhs are all valid if written as infix expressions:

 f = id $ \ _ - []
 g = id $ let x = [] in x
 h = id $ case [] of [] - []
 i = id $ do []
 j = id $ if True then [] else []

False.

f = runST $ do return ()

is a type error.

f = runST (do return ())

is legal.

So your proposal isn't as pointless as you think :)

 (In fact, maybe for haskell-prime $ could be changed to a keyword.)

 Does this pose any problems that I haven't considered?

Not that I know of.  Indeed, the status quo is a (minor) pain to parse,
and in my Haskell compiler project I *wanted* to implement your
proposal.

 I think only more (and shorter) illegal haskell programs will become legal.

 Cheers Christian

 Maybe someone else can work out the details for Haskell's grammar

Not hard at all.  In http://haskell.org/onlinereport/syntax-iso.html,
change:

exp^10 -  \ apat[1] ... apat[n] - exp (lambda abstraction, n=1)
   |   let decls in exp (let expression)
   |   if exp then exp else exp (conditional)
   |   case exp of { alts } (case expression)
   |   do { stmts } (do expression)
   |   fexp
fexp   -  [fexp] aexp  (function application)

aexp   -  qvar   (variable)
   |   gcon   (general constructor)
   |   literal
   |   ( exp )(parenthesized expression)
   |   ( exp[1] , ... , exp[k] )  (tuple, k=2)
   |   [ exp[1] , ... , exp[k] ]  (list, k=1)
   |   [ exp[1] [, exp[2]] .. [exp[3]] ]  (arithmetic sequence)
   |   [ exp | qual[1] , ... , qual[n] ]  (list comprehension, n=1)
   |   ( exp^i+1 qop^(a,i) )  (left section)
   |   ( lexp^i qop^(l,i) )   (left section)
   |   ( qop^(a,i)[-] exp^i+1 ) (right section)
   |   ( qop^(r,i)[-] rexp^i )  (right section)
   |   qcon { fbind[1] , ... , fbind[n] } (labeled construction, 
n=0)
   |   aexp[qcon] { fbind[1] , ... , fbind[n] } (labeled update, n = 1)

to:

exp^10 -  [exp^10] aexp(function application)
aexp   -  \ apat[1] ... apat[n] - exp (lambda abstraction, n=1)
   |   let decls in exp (let expression)
   |   if exp then exp else exp (conditional)
   |   case exp of { alts } (case expression)
   |   do { stmts } (do expression)
   |   qvar   (variable)
   |   gcon   (general constructor)
   |   literal
   |   ( exp )(parenthesized expression)
   |   ( exp[1] , ... , exp[k] )  (tuple, k=2)
   |   [ exp[1] , ... , exp[k] ]  (list, k=1)
   |   [ exp[1] [, exp[2]] .. [exp[3]] ]  (arithmetic sequence)
   |   [ exp | qual[1] , ... , qual[n] ]  (list comprehension, n=1)
   |   ( exp^i+1 qop^(a,i) )  (left section)
   |   ( lexp^i qop^(l,i) )   (left section)
   |   ( qop^(a,i)[-] exp^i+1 ) (right section)
   |   ( qop^(r,i)[-] rexp^i )  (right section)
   |   qcon { fbind[1] , ... , fbind[n] } (labeled construction, 
n=0)
   |   aexp[qcon] { fbind[1] , ... , fbind[n] } (labeled update, n = 1)

All new ambiguities are resolved adequately by the let/lambda meta rule.

 (I've posted this message to glasgow-haskell-users before, but it
 applies to every Haskell implementation and should be discussed here.)

haskell-prime@haskell.org would be even better.

Stefan


signature.asc
Description: Digital signature
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


Re: [Haskell-cafe] Haskell's prefix exprs

2007-07-09 Thread Isaac Dupree

Stefan O'Rear wrote:

On Mon, Jul 09, 2007 at 03:55:52PM +0200, Christian Maeder wrote:

Hi,

I would like haskell to accept the following (currently illegal)
expressions as syntactically valid prefix applications:

f = id \ _ - []
g = id let x = [] in x
h = id case [] of [] - []
i = id do []
j = id if True then [] else []


I agree.  The only (minor) concern I have is: that syntax is hard to 
read (by humans) without syntax-hilighting of keywords.


Isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime


monomorphism restriction confusions

2007-07-09 Thread Isaac Dupree
Haskell98's monomorphism restriction is too confusing!  See my mistaken 
GHC bug report http://hackage.haskell.org/trac/ghc/ticket/1503. 
Whether a binding is monomorphic depends not just on syntax, but on the 
amount of type constraints on the right-hand side of a binding - and I 
didn't realize, because this issue usually doesn't come up (usually 
types are already monomorphic or are at least typeclass qualified, or at 
least don't have to be monomorphic to prevent a type error).  Although 
this finally convinces me that we should dump H98 m-r in favor of the 
very straightforward monomorphic pattern bindings, if we don't, at 
least I believe that Report Section 4.5.5, Rule 1 needs a reword.  It 
uses (un) restricted to mean restricted (to be monomorphic) IN SOME 
CASES.  Maybe a word like suspicious would be less misleading than 
restricted there?


Isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime