headers
Simon Peyton-Jones | 1 Aug 2009 13:58
Picon
Favicon
Gravatar

RE: StricterLabelledFieldSyntax

Personally I hate the fact that
	f Z {x=3}
parses as 
	f (Z {a=3})
because even though (as Iavor says) there is only one function application involved, it *looks* as if there
are two.

Equally personally, I think that the presence or absence of white space is a powerful signal to
programmers, and it's a shame to deny ourselves use of it.  So I'd be quite happy with *requiring* there to be
no space, thus Z{ x=3 }.  If that's tricky to lex, so be it.  (Though a token
"BRACE_WITH_NO_PRECEDING_WHITESPACE" might do the job.)  But this would be a very
non-backward-compatible change.

Simon

| -----Original Message-----
| From: haskell-prime-bounces@... [mailto:haskell-prime-
| bounces@...] On Behalf Of Ian Lynagh
| Sent: 26 July 2009 21:53
| To: haskell-prime@...
| Subject: Re: StricterLabelledFieldSyntax
| 
| On Sun, Jul 26, 2009 at 10:16:28PM +0300, Iavor Diatchki wrote:
| >
| > On Sun, Jul 26, 2009 at 10:01 PM, Isaac
| > Dupree<ml@...> wrote:
| > > Iavor Diatchki wrote:
| > >>
| > >> I am strongly against this change.  The record notation works just
| > >> fine and has been doing so for a long time.  The notation is really
(Continue reading)

Permalink | Reply | 4 comments |
headers
Iavor Diatchki | 2 Aug 2009 10:05
Picon
Gravatar

Re: StricterLabelledFieldSyntax

Hello,
There are some examples where the current notation is nicer
(subjectively so, of course :-) with the white space.  Mostly, when
the record fields do not fit on a single line.  I tend to write things
like this:

ParseError
  { errorPosition = ..
  , errorDescription = ..
  }

alternatively:

ParseError {
  errorPosition = ..,
  errorDescription = ..
}

I think that it would be very odd if these did not work because the
brace had to be next to the constructor without white space.  The only
alternative I can see would be to have _two_ different notations for
creating records one with the space that requires parens,  and one
without that does not require parens but (at least to me) this looks
like a cludge, and is much more complex than the current situation.

-Iavor

On Sat, Aug 1, 2009 at 2:58 PM, Simon Peyton-Jones<simonpj@...> wrote:
> Personally I hate the fact that
>        f Z {x=3}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neil Mitchell | 2 Aug 2009 22:21
Picon
Gravatar

Re: Proposals and owners

>>>>  >  remove FixityResolution from the context-free grammar
>>>
>>> http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution
>>>
>>> Please take a look and comment.  This fixes a nasty bug in the Haskell
>>> syntax - albeit one that doesn't cause problems in practice, but still.
>>>  I
>>> think the changes make the grammar look nicer, and help compiler
>>> implementers by providing a sample implementation of fixity resolution.
>>>
>>> We better be sure the sample implementation is correct!  I've tested it
>>> fairly well, but I wouldn't rule out corner cases being wrong, especially
>>> with prefix negation.
>>
>> The code in Resolve.hs has been used by HLint for months, and is the
>> basis of the resolution used in haskell-src-exts 1.0.0. In that time I
>> haven't seen any bugs with the fixity resolution.
>
> I updated the code on the wiki page: the previous version didn't handle
> prefix negation - did you implement that yourself in HLint?

No, I didn't implement prefix negation in HLint - it never came up as
an issue. Perhaps the underlying HSE library dealt with it for me -
Niklas would know.

Thanks

Neil
Permalink | Reply | 2 comments |
headers
Niklas Broberg | 2 Aug 2009 23:38
Picon
Gravatar

Re: Proposals and owners

>> I updated the code on the wiki page: the previous version didn't handle
>> prefix negation - did you implement that yourself in HLint?
>
> No, I didn't implement prefix negation in HLint - it never came up as
> an issue. Perhaps the underlying HSE library dealt with it for me -
> Niklas would know.

In haskell-src-exts (and haskell-src, since that's inherited), unary
minus binds tighter than any infix operator:

> exp0b :: { PExp }
>       : exp0b qop exp10b              { InfixApp $1 $2 $3 }
>       | dvarexp                       { $1 }
>       | exp10b                        { $1 }

> exp10b :: { PExp }
>       : 'case' exp 'of' altslist      { Case $2 $4 }
>       | '-' fexp                      { NegApp $2 }
>       | 'do' stmtlist                 { Do $2 }
>       | 'mdo' stmtlist                { MDo $2 }
>       | fexp                          { $1 }

It has never come up as a problem. Guess that's a point in case for
getting rid of unary minus as an operator. :-)

Cheers,

/Niklas
Permalink | Reply | 1 comment |
headers
Simon Marlow | 3 Aug 2009 11:20
Picon

Re: Proposals and owners

On 02/08/2009 22:38, Niklas Broberg wrote:
>>> I updated the code on the wiki page: the previous version didn't handle
>>> prefix negation - did you implement that yourself in HLint?
>>
>> No, I didn't implement prefix negation in HLint - it never came up as
>> an issue. Perhaps the underlying HSE library dealt with it for me -
>> Niklas would know.
>
> In haskell-src-exts (and haskell-src, since that's inherited), unary
> minus binds tighter than any infix operator:
>
>> exp0b :: { PExp }
>>        : exp0b qop exp10b              { InfixApp $1 $2 $3 }
>>        | dvarexp                       { $1 }
>>        | exp10b                        { $1 }
>
>> exp10b :: { PExp }
>>        : 'case' exp 'of' altslist      { Case $2 $4 }
>>        | '-' fexp                      { NegApp $2 }
>>        | 'do' stmtlist                 { Do $2 }
>>        | 'mdo' stmtlist                { MDo $2 }
>>        | fexp                          { $1 }
>
> It has never come up as a problem. Guess that's a point in case for
> getting rid of unary minus as an operator. :-)

I think someone should propose this change for next year's Haskell 
revision.  We have evidence that (a) the current precedence of prefix 
negation is confusing, and (b) it is rarely relied upon.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 3 Aug 2009 11:20
Picon

Re: Proposals and owners

So is there a volunteer to flesh out the details of a proposal?

On 31/07/2009 16:53, Iavor Diatchki wrote:
> +1. I completely agree.
>
> On Fri, Jul 31, 2009 at 6:04 PM, Lennart
> Augustsson<lennart@...>  wrote:
>> I think that a natural extension to allowing empty data declarations
>> would be to allow empty case expressions.
>>
>> On Wed, Jul 29, 2009 at 7:34 PM, Stephanie
>> Weirich<sweirich@...>  wrote:
>>> Ok, I've put together a page on EmptyDataDecls:
>>>
>>> http://hackage.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls
>>>
>>> Cheers,
>>> Stephanie
>>> _______________________________________________
>>> Haskell-prime mailing list
>>> Haskell-prime@...
>>> http://www.haskell.org/mailman/listinfo/haskell-prime
>>>
>> _______________________________________________
>> Haskell-prime mailing list
>> Haskell-prime@...
>> http://www.haskell.org/mailman/listinfo/haskell-prime
>>
> _______________________________________________
> Haskell-prime mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 3 Aug 2009 11:29
Picon

Re: StricterLabelledFieldSyntax

On 01/08/2009 12:58, Simon Peyton-Jones wrote:
> Personally I hate the fact that
> 	f Z {x=3}
> parses as
> 	f (Z {a=3})
> because even though (as Iavor says) there is only one function application involved, it *looks* as if
there are two.
>
> Equally personally, I think that the presence or absence of white space is a powerful signal to
programmers, and it's a shame to deny ourselves use of it.  So I'd be quite happy with *requiring* there to be
no space, thus Z{ x=3 }.  If that's tricky to lex, so be it.  (Though a token
"BRACE_WITH_NO_PRECEDING_WHITESPACE" might do the job.)  But this would be a very
non-backward-compatible change.

On this point - I agree that whitespace-sensitive syntax presents no 
problem to programmers, and is often quite natural.  However, I think it 
presents enough other problems that it should be avoided where possible.

I'm thinking of

  - being friendly to automatic program generation
  - being friendly to parsers, and tools that grok Haskell
  - making code robust to modification that changes whitespace
  - making the grammar (in the report) simpler

all of these things are hurt by whitespace-sensitive syntax.  IMO, we 
should think very carefully before introducing any.

Cheers,
	Simon
(Continue reading)

Permalink | Reply | 2 comments |
headers
Malcolm Wallace | 3 Aug 2009 11:44
Picon

Re: StricterLabelledFieldSyntax

> all of these things are hurt by whitespace-sensitive syntax.  IMO,  
> we should think very carefully before introducing any.

Haskell already has plenty of whitespace sensitivity.  The layout rule  
is a pretty major part of the tradition.  Other places:

   * (Just.foo) differs from (Just . foo)
   * --|        differs from -- |
   * With NegativeSyntax, (-1) would differ from (- 1)
   * In TemplateHaskell,  $x   differs from  $ x
   * In TemplateHaskell,  [d|  differs from  [ d |
   * With UnboxedTypes,   (#   differs from  ( #
   * With UnboxedTypes,   3#   differs from  3 #

Regards,
     Malcolm
Permalink | Reply | 1 comment |
headers
Simon Marlow | 3 Aug 2009 12:12
Picon

Re: StricterLabelledFieldSyntax

On 03/08/2009 10:44, Malcolm Wallace wrote:
>> all of these things are hurt by whitespace-sensitive syntax.  IMO, we
>> should think very carefully before introducing any.
>
> Haskell already has plenty of whitespace sensitivity. The layout rule is
> a pretty major part of the tradition. Other places:
>
> * (Just.foo) differs from (Just . foo)
> * --| differs from -- |
> * With NegativeSyntax, (-1) would differ from (- 1)
> * In TemplateHaskell, $x differs from $ x
> * In TemplateHaskell, [d| differs from [ d |
> * With UnboxedTypes, (# differs from ( #
> * With UnboxedTypes, 3# differs from 3 #

Yes, I know.  There's also numbers: 1.0, 1e3, 0xFF.  And strictly 
speaking keywords are also in violation: "where by" vs. "whereby", 
although I wouldn't go so far as to suggest we change that, of course.

Only the first two items in your list are actually in Haskell, 
incedentally, and I argued against the others.  The problem is it's hard 
to find spare syntax, especially for brackets, without either adding 
whitespace-sensitivity or using non-ASCII characters.

The layout rule doesn't count, at least for the kind of 
whitespace-sensitivity I'm worried about, which is the presence/absence 
of whitespace rather than the quantity or composition of it.

Cheers,
	Simon
(Continue reading)

Permalink | Reply | 0 comments |
headers
Malcolm Wallace | 6 Aug 2009 12:08
Picon

bug in language definition (strictness)

It has been brought to my attention (as errata editor of the revised  
H'98 report) that there is a bug in the language definition,  
concerning strictness annotations on datatypes.

In section 4.2.1, the translation of strict components of a data  
constructor is defined as
> (\ x1 ... xn -> ( ((K op1 x1) op2 x2) ... ) opn xn)
>
> where opi is the non-strict apply function $ if si is of the form  
> ti, and opi is the strict apply function $! (see Section 6.2) if si  
> is of the form ! ti. Pattern matching on K is not affected by  
> strictness flags.
>

yet, because of the definition of $!, this applies the constructor to  
its arguments right-to-left instead of the intuitive left-to-right.   
All extant compilers in fact evaluate the strict fields left-to-right  
in violation of the Report.

The same non-intuitive behaviour can be seen more clearly in the  
simple expression:

     (f $! x) $! y

in which you might expect x to be evaluated before y, but in fact it  
is the other way round.  (And here, the compilers do follow the Report.)

The fix I propose for H'98 (and equally for Haskell Prime) is to  
change the definition of $! as follows
(Continue reading)

Permalink | Reply | 0 comments |

Gmane