From ian at well-typed.com  Fri Feb  1 18:10:42 2013
From: ian at well-typed.com (Ian Lynagh)
Date: Fri, 1 Feb 2013 17:10:42 +0000
Subject: Bang patterns
Message-ID: <20130201171042.GA7743@matrix.chaos.earth.li>


Hi all,

I would like to get a full specification of the bang patterns syntax,
partly so it can be proposed for H', and partly so we can resolve
tickets like http://hackage.haskell.org/trac/ghc/ticket/1087 correctly.


I think there are 3 possibilities:



The first is suggested by "A bang only really has an effect if it
precedes a variable or wild-card pattern" on
http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns

We could therefore alter the lexical syntax to make strict things into
lexems, for example
    reservedid -> ...
                | _
                | !_
    strictvarid -> ! varid
etc. This would mean that "f !x" is 2 lexemes, and "f ! x" 3 lexemes,
with the former defining the function 'f' and the latter defining the
operator '!'.

This has 3 downsides:

* It would require also accepting the more radical proposal of making
  let strict, as it would no longer be possible to write
    let ![x,y] = undefined in ()

* It would mean that "f !x" and "f !(x)" are different. Probably not a
  big issue in practice.

* It may interact badly with other future extensions. For example,
    {-# LANGUAGE ViewPatterns #-}
    f !(view -> x) = ()
  should arguably be strict in x.
  (you might also argue that it should define the operator '!'.
  Currently, in ghc, it defines an 'f' that is lazy in x, which IMO is a
  bug).



The second is to parse '!' differently depending on whether or not it is
followed by a space. In the absence of a decision to require infix
operators to be surrounded by spaces, I think this is a bad idea: Tricky
to specify, and to understand.



The third is to parse '!' in patterns in the same way that '~' is parsed
in patterns, except that (!) would be accepted as binding the operator
'!'. This means that "f ! x" defines f.



So my proposal would be to go with option 3. What do you think? And did
I miss any better options?


Thanks
Ian



From ian at well-typed.com  Fri Feb  1 18:17:17 2013
From: ian at well-typed.com (Ian Lynagh)
Date: Fri, 1 Feb 2013 17:17:17 +0000
Subject: Status of Haskell'?
In-Reply-To: <B72ED072-AFBC-48D9-964A-F3017CCDA0A4@me.com>
References: <CAB7CYTwh-CAODjBX0uErDaU4ay8-7Uz2d_OMAeWfkc3dvpEdhA@mail.gmail.com>
	<CAKFCL4VY2eW2HvC4+ueZryU3f-eedkiKRO02EW6ObaFXfJm4qQ@mail.gmail.com>
	<20121127173534.GB12220@matrix.chaos.earth.li>
	<CAJhrHS0tQ=7spvkQ9LWzxGz6ucTa2ST5xGAX4-44RbHqcjXsGA@mail.gmail.com>
	<CAB7CYTzhMHuFzHCpm7S=aXYsGU8sKjk3gTJxQpqc0rgtDOH_8A@mail.gmail.com>
	<59543203684B2244980D7E4057D5FBC13F7853B5@DB3EX14MBXC308.europe.corp.microsoft.com>
	<83657A6B-D673-476C-869A-24F9EBE8FBF5@vectorfabrics.com>
	<59543203684B2244980D7E4057D5FBC13F78A1CC@DB3EX14MBXC308.europe.corp.microsoft.com>
	<CAMej=25vAnVqH=DZQiw9zMsO5gV=ut=SkepwLuPrUmMh_9n=fw@mail.gmail.com>
	<B72ED072-AFBC-48D9-964A-F3017CCDA0A4@me.com>
Message-ID: <20130201171717.GA7798@matrix.chaos.earth.li>


Hi Malcolm,

On Wed, Dec 12, 2012 at 10:40:53AM +0000, Malcolm Wallace wrote:
> 
> Please send nominations to haskell-2011-committee at haskell.org, summarising your interest and experience.  The existing committee will (I hope) make some decision on how to proceed, in early January 2013.

Any progress on this?


Thanks
Ian



From malcolm.wallace at me.com  Fri Feb  1 18:31:53 2013
From: malcolm.wallace at me.com (malcolm.wallace)
Date: Fri, 01 Feb 2013 17:31:53 +0000 (GMT)
Subject: Status of Haskell'?
In-Reply-To: <20130201171717.GA7798@matrix.chaos.earth.li>
Message-ID: <f7d3ad1f-ed67-48c2-8e76-796a51a2d7af@me.com>

The committee has received no nominations. ?I have asked the committee whether they would like to disband.
Regards,
    Malcolm

On 01 Feb, 2013,at 05:17 PM, Ian Lynagh <ian at well-typed.com> wrote:


Hi Malcolm,

On Wed, Dec 12, 2012 at 10:40:53AM +0000, Malcolm Wallace wrote:
> 
> Please send nominations to haskell-2011-committee at haskell.org, summarising your interest and experience. The existing committee will (I hope) make some decision on how to proceed, in early January 2013.

Any progress on this?


Thanks
Ian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-prime/attachments/20130201/73f7371e/attachment.htm>

From ian at well-typed.com  Fri Feb  1 18:37:31 2013
From: ian at well-typed.com (Ian Lynagh)
Date: Fri, 1 Feb 2013 17:37:31 +0000
Subject: Status of Haskell'?
In-Reply-To: <f7d3ad1f-ed67-48c2-8e76-796a51a2d7af@me.com>
References: <20130201171717.GA7798@matrix.chaos.earth.li>
	<f7d3ad1f-ed67-48c2-8e76-796a51a2d7af@me.com>
Message-ID: <20130201173730.GA8280@matrix.chaos.earth.li>

On Fri, Feb 01, 2013 at 05:31:53PM +0000, Malcolm Wallace wrote:
> The committee has received no nominations.

At least one was sent. Does haskell-2011-committee at haskell.org accept
mails from non-members?


Thanks
Ian



From haskell at benmachine.co.uk  Sun Feb  3 23:34:04 2013
From: haskell at benmachine.co.uk (Ben Millwood)
Date: Sun, 3 Feb 2013 22:34:04 +0000
Subject: Bang patterns
In-Reply-To: <20130201171042.GA7743@matrix.chaos.earth.li>
References: <20130201171042.GA7743@matrix.chaos.earth.li>
Message-ID: <20130203223404.GA24375@euler.dow.cam.ac.uk>

On Fri, Feb 01, 2013 at 05:10:42PM +0000, Ian Lynagh wrote:
>
>The first is suggested by "A bang only really has an effect if it
>precedes a variable or wild-card pattern" on
>http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns
>
>We could therefore alter the lexical syntax to make strict things into
>lexems, for example
>    reservedid -> ...
>                | _
>                | !_
>    strictvarid -> ! varid
>etc. This would mean that "f !x" is 2 lexemes, and "f ! x" 3 lexemes,
>with the former defining the function 'f' and the latter defining the
>operator '!'.
>
>This has 3 downsides:
>
>* It would require also accepting the more radical proposal of making
>  let strict, as it would no longer be possible to write
>    let ![x,y] = undefined in ()

We really can't make let strict, in my view: its laziness is sort of 
fundamental. I don't see why the given example necessitates it though: 
just use case-of in that scenario. In fact, I've kind of always been 
uncomfortable with bang patterns in let-statements. I feel like I should 
be able to omit an unused let-binding without affecting my program at 
all, and bang patterns in let make that no longer true.

>* It would mean that "f !x" and "f !(x)" are different. Probably not a
>  big issue in practice.

Yeah, I'm not upset about this. We'd be thinking of the ! as a decorator 
in the same way that, say, infix-backticks are: we don't expect `(foo)` 
to work.

>* It may interact badly with other future extensions. For example,
>    {-# LANGUAGE ViewPatterns #-}
>    f !(view -> x) = ()
>  should arguably be strict in x.
>  (you might also argue that it should define the operator '!'.
>  Currently, in ghc, it defines an 'f' that is lazy in x, which IMO is a
>  bug).

Hmm. Not quite strict in x. I'd think the right way to make that strict 
in x is:

      f (view -> !x) = ()

What you want is possibly to evaluate the thing you pass to the view 
/before/ matching on the result. But I imagine that in most cases your 
view function will be strict so the difference will be immaterial.

I agree that GHC current behaviour looks like a bug.

>The second is to parse '!' differently depending on whether or not it is
>followed by a space. In the absence of a decision to require infix
>operators to be surrounded by spaces, I think this is a bad idea: Tricky
>to specify, and to understand.

Hmm. It's a shame because in real code operator definitions are almost 
invariably surrounded by spaces, even when the use of the operator 
wouldn't be. But I agree in general.

>The third is to parse '!' in patterns in the same way that '~' is parsed
>in patterns, except that (!) would be accepted as binding the operator
>'!'. This means that "f ! x" defines f.

This is roughly how it's done at present, right? It's annoyingly 
inconsistent, but fairly low-impact.

>So my proposal would be to go with option 3. What do you think? And did
>I miss any better options?

You missed the option of going the way of ~ and making ! an illegal name 
for an operator. Obvious drawbacks, probably not a good idea, but it 
would be the most consistent solution, so I wouldn't dismiss it 
immediately.

(If we do come up with a way that doesn't involve making ! illegal, 
maybe we should consider allowing ~ as an operator as well!)

There's another alternative entirely, that I haven't really thought 
about: introduce bang patterns on types instead of on variables. I 
realise this is less flexible, but! it covers many common cases, it 
avoids the infix confusion altogether, it echoes the existing usage for 
strict datatypes, and it makes the strictness of a function 
(potentially) part of its type signature, which would be handy in 
documentation. I realise this is a bit late in the game to be including 
this option, but if it doesn't get thought about now, it never will.

Anyway, in light of my above comments, I think I like the first option 
the best (so bang patterns only apply to variables, let doesn't become 
strict).

regards,
Ben


From ian at well-typed.com  Mon Feb  4 00:22:12 2013
From: ian at well-typed.com (Ian Lynagh)
Date: Sun, 3 Feb 2013 23:22:12 +0000
Subject: Bang patterns
In-Reply-To: <20130203223404.GA24375@euler.dow.cam.ac.uk>
References: <20130201171042.GA7743@matrix.chaos.earth.li>
	<20130203223404.GA24375@euler.dow.cam.ac.uk>
Message-ID: <20130203232212.GA22702@matrix.chaos.earth.li>

On Sun, Feb 03, 2013 at 10:34:04PM +0000, Ben Millwood wrote:
> On Fri, Feb 01, 2013 at 05:10:42PM +0000, Ian Lynagh wrote:
> >
> >The first is suggested by "A bang only really has an effect if it
> >precedes a variable or wild-card pattern" on
> >http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns
> >
> >We could therefore alter the lexical syntax to make strict things into
> >lexems, for example
> >   reservedid -> ...
> >               | _
> >               | !_
> >   strictvarid -> ! varid
> >etc. This would mean that "f !x" is 2 lexemes, and "f ! x" 3 lexemes,
> >with the former defining the function 'f' and the latter defining the
> >operator '!'.
> >
> >This has 3 downsides:
> >
> >* It would require also accepting the more radical proposal of making
> > let strict, as it would no longer be possible to write
> >   let ![x,y] = undefined in ()
> 
> We really can't make let strict, in my view: its laziness is sort of
> fundamental. I don't see why the given example necessitates it
> though: just use case-of in that scenario.

Well, true, that's another option. It's rather unpleasant when you have
multiple bindings, as when converted to 'case's, each 'case' requires
you to indent deeper (or to use more braces).

> >The third is to parse '!' in patterns in the same way that '~' is parsed
> >in patterns, except that (!) would be accepted as binding the operator
> >'!'. This means that "f ! x" defines f.
> 
> This is roughly how it's done at present, right?

I think it's roughly what GHC does now, yes.

> You missed the option of going the way of ~ and making ! an illegal
> name for an operator. Obvious drawbacks, probably not a good idea,
> but it would be the most consistent solution, so I wouldn't dismiss
> it immediately.

Yes, OK. That's basically option 3 as far as patterns are concerned, but
also disallows ! as an operator.

> (If we do come up with a way that doesn't involve making ! illegal,
> maybe we should consider allowing ~ as an operator as well!)

Right, if we went for option 3 then making ~ an operator in the same way
as ! would be possible. I think we should be cautious about doing so,
though, as it's a semi-one-way change, i.e. once it's an operator and
people start using it it becomes a lot trickier to revert the decision.

> Anyway, in light of my above comments, I think I like the first
> option the best (so bang patterns only apply to variables, let
> doesn't become strict).

So just to clarify what you're proposing, this wouldn't be valid:
    let ![x] = e in ...
and I guess these wouldn't either?:
    let !x = e in ...
    let [!x] = e in ...
    let (x, ~(y, !z)) = e in ...
but these would?:
    let f !x = e in ...
    case x of ~(y, !z) -> ()

i.e. you wouldn't be able to use ! in the 'pat' in the
    decl -> pat rhs
production.

You'd also no longer support:
    do ![x]          <- e; ...
and so again for consistency I guess these wouldn't work?:
    do !x            <- e; ...
    do [!x]          <- e; ...
    do (x, ~(y, !z)) <- e; ...

i.e. you also wouldn't be able to use ! in the 'pat' in the
    stmt -> pat <- exp ;
production.


Thanks
Ian



From haskell at benmachine.co.uk  Mon Feb  4 01:44:53 2013
From: haskell at benmachine.co.uk (Ben Millwood)
Date: Mon, 4 Feb 2013 00:44:53 +0000
Subject: Bang patterns
In-Reply-To: <20130203232212.GA22702@matrix.chaos.earth.li>
References: <20130201171042.GA7743@matrix.chaos.earth.li>
	<20130203223404.GA24375@euler.dow.cam.ac.uk>
	<20130203232212.GA22702@matrix.chaos.earth.li>
Message-ID: <20130204004453.GE29536@euler.dow.cam.ac.uk>

On Sun, Feb 03, 2013 at 11:22:12PM +0000, Ian Lynagh wrote:
>On Sun, Feb 03, 2013 at 10:34:04PM +0000, Ben Millwood wrote:
>> On Fri, Feb 01, 2013 at 05:10:42PM +0000, Ian Lynagh wrote:
>> >
>> >The first is suggested by "A bang only really has an effect if it
>> >precedes a variable or wild-card pattern" on
>> >http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns
>> >
>> >We could therefore alter the lexical syntax to make strict things into
>> >lexems, for example
>> >   reservedid -> ...
>> >               | _
>> >               | !_
>> >   strictvarid -> ! varid
>> >etc. This would mean that "f !x" is 2 lexemes, and "f ! x" 3 lexemes,
>> >with the former defining the function 'f' and the latter defining the
>> >operator '!'.
>> >
>> >This has 3 downsides:
>> >
>> >* It would require also accepting the more radical proposal of making
>> > let strict, as it would no longer be possible to write
>> >   let ![x,y] = undefined in ()
>>
>> We really can't make let strict, in my view: its laziness is sort of
>> fundamental. I don't see why the given example necessitates it
>> though: just use case-of in that scenario.
>
>Well, true, that's another option. It's rather unpleasant when you have
>multiple bindings, as when converted to 'case's, each 'case' requires
>you to indent deeper (or to use more braces).

Yes, or you could use a tuple, or you could use seq directly, but I 
recognise those options as having their own drawbacks.

(Observation: if bang patterns are made primitive, seq can be implemented 
as an ordinary function in terms of them.)

>> (If we do come up with a way that doesn't involve making ! illegal,
>> maybe we should consider allowing ~ as an operator as well!)
>
>Right, if we went for option 3 then making ~ an operator in the same way
>as ! would be possible. I think we should be cautious about doing so,
>though, as it's a semi-one-way change, i.e. once it's an operator and
>people start using it it becomes a lot trickier to revert the decision.

Yeah, I wouldn't be overeager to do it, just worth remembering that that 
option becomes open.

>> Anyway, in light of my above comments, I think I like the first
>> option the best (so bang patterns only apply to variables, let
>> doesn't become strict).
>
>So just to clarify what you're proposing, this wouldn't be valid:
>    let ![x] = e in ...
>and I guess these wouldn't either?:
>    let !x = e in ...
>    let [!x] = e in ...
>    let (x, ~(y, !z)) = e in ...
>but these would?:
>    let f !x = e in ...
>    case x of ~(y, !z) -> ()

I have two proposals, I suppose:
- make bang patterns operate only on variables and wildcards
- make bang patterns in let altogether invalid

(with an optional third, "make bang patterns something else entirely")

with the justification for the first being that it is the most common 
case and interferes less with the infix operator !, and the 
justification for the second being the somewhat weedier general notion 
that I think unused let bindings should be discardable, and that I think 
bang-lets confuse the distinction between case and let (but then, 
arguably ~ already does that).

So, my proposal is the following definitely ARE allowed:

>    let f !x = e in ...
>    case x of ~(y, !z) -> ()

The following definitely AREN'T:

>    let ![x] = e in ...
>    do ![x]          <- e; ...

but the following are allowed by the first proposal but disallowed by 
the second:

>    let !x = e in ...
>    let [!x] = e in ...
>    let (x, ~(y, !z)) = e in ...
>    do !x            <- e; ...
>    do [!x]          <- e; ...
>    do (x, ~(y, !z)) <- e; ...

I'm not committed to this plan. I can see especially why the second 
pattern on my forbidden list might be useful. But I don't like making 
operator-! special.

(I still think types might be the right place to put this information).

Thanks,
Ben


From ian at well-typed.com  Mon Feb  4 02:20:18 2013
From: ian at well-typed.com (Ian Lynagh)
Date: Mon, 4 Feb 2013 01:20:18 +0000
Subject: Bang patterns
In-Reply-To: <20130204004453.GE29536@euler.dow.cam.ac.uk>
References: <20130201171042.GA7743@matrix.chaos.earth.li>
	<20130203223404.GA24375@euler.dow.cam.ac.uk>
	<20130203232212.GA22702@matrix.chaos.earth.li>
	<20130204004453.GE29536@euler.dow.cam.ac.uk>
Message-ID: <20130204012018.GA24206@matrix.chaos.earth.li>

On Mon, Feb 04, 2013 at 12:44:53AM +0000, Ben Millwood wrote:
> 
> I have two proposals, I suppose:
> - make bang patterns operate only on variables and wildcards
> - make bang patterns in let altogether invalid

Looking at this again made me realise that, as well as !_ and !varid
lexemes, we could also alter the decl production so that we get
    decl -> ...
          | pat rhs     -- existing lazy binding production
          | '!' pat rhs -- new strict binding production

That means that
    let !(x, y) = e in ...
would still be valid, with the ! not actually being parsed as part of
the pattern, but would parse instead as a strict binding. It would be
a little ugly under the hood, as
    let !x = e in ...
would parse as a lazy binding, although we'd want to treat it as a
strict binding anyway.


Thanks
Ian



From malcolm.wallace at me.com  Mon Feb  4 12:26:25 2013
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Mon, 04 Feb 2013 11:26:25 +0000
Subject: Call for Nominations: Haskell Prime language committee
Message-ID: <EB2A14E8-8425-49E5-82BC-DA312AC1DDF5@me.com>

Dear Haskell lovers,

The Haskell Prime process for standardisation of new versions of the Haskell language is at something of an impasse.  Since the Haskell 2010 Report was issued (at the end of 2009), there has been very little momentum to formalise existing extensions and generalisations, nor appetite to decide on whether any such extensions should be adopted as part of the core language standard.

We therefore seek nominations for new members of the Haskell Prime language committee; people who have the enthusiasm to take this forward, as well as some relevant experience.

If you think you would like to contribute, please nominate yourself by sending a email to

    haskell-2011-committee at haskell.org

describing who you are, and what you think the committee might hope to achieve.  The address above
is populated by the existing committee members, but is now (temporarily) open to all during the nomination period.  Nominations close in 3 weeks time, i.e. to be received by end of Sunday 24th February 2013.

The process for deciding a new language committee is described at

    http://hackage.haskell.org/trac/haskell-prime/wiki/Committee

Regards,
    Malcolm


From johan.tibell at gmail.com  Mon Feb  4 22:21:31 2013
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 4 Feb 2013 13:21:31 -0800
Subject: Bang patterns
In-Reply-To: <20130204004453.GE29536@euler.dow.cam.ac.uk>
References: <20130201171042.GA7743@matrix.chaos.earth.li>
	<20130203223404.GA24375@euler.dow.cam.ac.uk>
	<20130203232212.GA22702@matrix.chaos.earth.li>
	<20130204004453.GE29536@euler.dow.cam.ac.uk>
Message-ID: <CAK-tuPaqwb4ZGQEnZ=T5xA5MKC9QFOSeod08vGPyF=zU1bp0Eg@mail.gmail.com>

On Sun, Feb 3, 2013 at 4:44 PM, Ben Millwood <haskell at benmachine.co.uk> wrote:
> I have two proposals, I suppose:
> - make bang patterns in let altogether invalid

I would prefer it to be valid. It's the syntactically most lightweight
option we have to force some thunks before using the resulting values
in a constructor that we have. Example

    let !x = ...
        !y = ...
    in C x y

The alternative would be

    let x = ...
        y = ...
    in x `seq` y `seq` C x y

which obscures the code much more.

My 2 cents.

-- Johan


From simonpj at microsoft.com  Mon Feb  4 23:37:44 2013
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Mon, 4 Feb 2013 22:37:44 +0000
Subject: Bang patterns
In-Reply-To: <20130204012018.GA24206@matrix.chaos.earth.li>
References: <20130201171042.GA7743@matrix.chaos.earth.li>
	<20130203223404.GA24375@euler.dow.cam.ac.uk>
	<20130203232212.GA22702@matrix.chaos.earth.li>
	<20130204004453.GE29536@euler.dow.cam.ac.uk>
	<20130204012018.GA24206@matrix.chaos.earth.li>
Message-ID: <59543203684B2244980D7E4057D5FBC147726CC4@DB3EX14MBXC312.europe.corp.microsoft.com>

|  > I have two proposals, I suppose:
|  > - make bang patterns operate only on variables and wildcards
|  > - make bang patterns in let altogether invalid
|  
|  Looking at this again made me realise that, as well as !_ and !varid
|  lexemes, we could also alter the decl production so that we get
|      decl -> ...
|            | pat rhs     -- existing lazy binding production
|            | '!' pat rhs -- new strict binding production
|  
|  That means that
|      let !(x, y) = e in ...
|  would still be valid, with the ! not actually being parsed as part of
|  the pattern, but would parse instead as a strict binding. 

Yes, I like this.  You could see the 
	'!' pat rhs
production as cancelling the implied '~' that a let-binding usually gets (see the desugaring for lets in the report).

A bang really only makes sense
* At the top of a let, to cancel the implied '~'.  Like Johan I
   am very strongly in favour of using ! for this purpose.
* On a varid or '_', which otherwise match lazily
Hence Ian's proposal, which treats these two separately, makes sense.

For example, there's no point in the pattern (x, !(y,z)), because it behaves identically to (x, (y,z)).

We really do need to allow
	f  !x  y !z = e
to mean f is strict in x and z.  There is an ambiguity here with a infix definition of (!), but it must be resolved in favour of the bang-pattern version.

I don't have a strong opinion about whether
	f ! x y ! z = e
should mean the same; ie whether the space is significant.   I think it's probably more confusing if the space is significant (so its presence or absence makes a difference).

Simon




From ian at well-typed.com  Tue Feb  5 00:42:08 2013
From: ian at well-typed.com (Ian Lynagh)
Date: Mon, 4 Feb 2013 23:42:08 +0000
Subject: Bang patterns
In-Reply-To: <59543203684B2244980D7E4057D5FBC147726CC4@DB3EX14MBXC312.europe.corp.microsoft.com>
References: <20130201171042.GA7743@matrix.chaos.earth.li>
	<20130203223404.GA24375@euler.dow.cam.ac.uk>
	<20130203232212.GA22702@matrix.chaos.earth.li>
	<20130204004453.GE29536@euler.dow.cam.ac.uk>
	<20130204012018.GA24206@matrix.chaos.earth.li>
	<59543203684B2244980D7E4057D5FBC147726CC4@DB3EX14MBXC312.europe.corp.microsoft.com>
Message-ID: <20130204234208.GA25210@matrix.chaos.earth.li>

On Mon, Feb 04, 2013 at 10:37:44PM +0000, Simon Peyton-Jones wrote:
> 
> I don't have a strong opinion about whether
> 	f ! x y ! z = e
> should mean the same; ie whether the space is significant.   I think it's probably more confusing if the space is significant (so its presence or absence makes a difference).

I also don't feel strongly, although I lean the other way:

I don't think anyone writes "f ! x" when they mean "f with a strict
argument x", and I don't see any particular advantage in allowing it.
In fact, I think writing that is less clear than "f !x", so there is an
advantage in disallowing it.

It also means that existing code that defines a (!) operator in infix
style would continue to work, provided it puts whitespace around the !. 


Thanks
Ian



From haskell at benmachine.co.uk  Tue Feb  5 01:24:51 2013
From: haskell at benmachine.co.uk (Ben Millwood)
Date: Tue, 5 Feb 2013 00:24:51 +0000
Subject: Bang patterns
In-Reply-To: <CAK-tuPaqwb4ZGQEnZ=T5xA5MKC9QFOSeod08vGPyF=zU1bp0Eg@mail.gmail.com>
References: <20130201171042.GA7743@matrix.chaos.earth.li>
	<20130203223404.GA24375@euler.dow.cam.ac.uk>
	<20130203232212.GA22702@matrix.chaos.earth.li>
	<20130204004453.GE29536@euler.dow.cam.ac.uk>
	<CAK-tuPaqwb4ZGQEnZ=T5xA5MKC9QFOSeod08vGPyF=zU1bp0Eg@mail.gmail.com>
Message-ID: <20130205002451.GB12052@euler.dow.cam.ac.uk>

On Mon, Feb 04, 2013 at 01:21:31PM -0800, Johan Tibell wrote:
>On Sun, Feb 3, 2013 at 4:44 PM, Ben Millwood <haskell at benmachine.co.uk> wrote:
>> I have two proposals, I suppose:
>> - make bang patterns in let altogether invalid
>
>I would prefer it to be valid. It's the syntactically most lightweight
>option we have to force some thunks before using the resulting values
>in a constructor that we have. Example
>
>    let !x = ...
>        !y = ...
>    in C x y
>
>The alternative would be
>
>    let x = ...
>        y = ...
>    in x `seq` y `seq` C x y
>
>which obscures the code much more.

I'd write (C $! x) $! y. We could devise a left-associative $! to avoid 
the use of parentheses here. But my objection was only ever a mild 
unease in any case, so I'm happy to dismiss it.

Ben


From ekmett at gmail.com  Tue Feb  5 01:26:16 2013
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 4 Feb 2013 19:26:16 -0500
Subject: Bang patterns
In-Reply-To: <20130204234208.GA25210@matrix.chaos.earth.li>
References: <20130201171042.GA7743@matrix.chaos.earth.li>
	<20130203223404.GA24375@euler.dow.cam.ac.uk>
	<20130203232212.GA22702@matrix.chaos.earth.li>
	<20130204004453.GE29536@euler.dow.cam.ac.uk>
	<20130204012018.GA24206@matrix.chaos.earth.li>
	<59543203684B2244980D7E4057D5FBC147726CC4@DB3EX14MBXC312.europe.corp.microsoft.com>
	<20130204234208.GA25210@matrix.chaos.earth.li>
Message-ID: <CAJumaK8bH3=VbZQORxcFA0RyGGCeoRb1ieDJVempr8Wi7BVnMw@mail.gmail.com>

If space sensitivity or () disambiguation is being used on !, could one of
these also be permitted on ~ to permit it as a valid infix term-level
operator?

That would be an amazingly valuable symbol to be able to reclaim for the
term level for equivalences, and for folks who come from other languages
where it is used like liftA2 (,) in parsing libraries, etc.

-Edward

On Mon, Feb 4, 2013 at 6:42 PM, Ian Lynagh <ian at well-typed.com> wrote:

> On Mon, Feb 04, 2013 at 10:37:44PM +0000, Simon Peyton-Jones wrote:
> >
> > I don't have a strong opinion about whether
> >       f ! x y ! z = e
> > should mean the same; ie whether the space is significant.   I think
> it's probably more confusing if the space is significant (so its presence
> or absence makes a difference).
>
> I also don't feel strongly, although I lean the other way:
>
> I don't think anyone writes "f ! x" when they mean "f with a strict
> argument x", and I don't see any particular advantage in allowing it.
> In fact, I think writing that is less clear than "f !x", so there is an
> advantage in disallowing it.
>
> It also means that existing code that defines a (!) operator in infix
> style would continue to work, provided it puts whitespace around the !.
>
>
> Thanks
> Ian
>
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-prime/attachments/20130204/a70fb8c1/attachment.htm>

From ian at well-typed.com  Tue Feb  5 14:42:47 2013
From: ian at well-typed.com (Ian Lynagh)
Date: Tue, 5 Feb 2013 13:42:47 +0000
Subject: Bang patterns
In-Reply-To: <CAJumaK8bH3=VbZQORxcFA0RyGGCeoRb1ieDJVempr8Wi7BVnMw@mail.gmail.com>
References: <20130201171042.GA7743@matrix.chaos.earth.li>
	<20130203223404.GA24375@euler.dow.cam.ac.uk>
	<20130203232212.GA22702@matrix.chaos.earth.li>
	<20130204004453.GE29536@euler.dow.cam.ac.uk>
	<20130204012018.GA24206@matrix.chaos.earth.li>
	<59543203684B2244980D7E4057D5FBC147726CC4@DB3EX14MBXC312.europe.corp.microsoft.com>
	<20130204234208.GA25210@matrix.chaos.earth.li>
	<CAJumaK8bH3=VbZQORxcFA0RyGGCeoRb1ieDJVempr8Wi7BVnMw@mail.gmail.com>
Message-ID: <20130205134247.GA9486@matrix.chaos.earth.li>

On Mon, Feb 04, 2013 at 07:26:16PM -0500, Edward Kmett wrote:
> If space sensitivity or () disambiguation is being used on !, could one of
> these also be permitted on ~ to permit it as a valid infix term-level
> operator?

I don't think there's any reason ~ couldn't be an operator, defined with
the
    (~) x y = ...
syntax.

Allowing it to be defined with infix syntax would be a little trickier.


Hmm, I've just realised that if we decide to make !_ and !foo lexemes,
then we'd also want !(+) to be a lexeme, which presumably means we'd
want (+) to be a single lexeme too (and also `foo`, for consistency).
But I don't think making that change would be problematic.


Thanks
Ian



From ekmett at gmail.com  Tue Feb  5 17:24:49 2013
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 5 Feb 2013 11:24:49 -0500
Subject: Bang patterns
In-Reply-To: <20130205134247.GA9486@matrix.chaos.earth.li>
References: <20130201171042.GA7743@matrix.chaos.earth.li>
	<20130203223404.GA24375@euler.dow.cam.ac.uk>
	<20130203232212.GA22702@matrix.chaos.earth.li>
	<20130204004453.GE29536@euler.dow.cam.ac.uk>
	<20130204012018.GA24206@matrix.chaos.earth.li>
	<59543203684B2244980D7E4057D5FBC147726CC4@DB3EX14MBXC312.europe.corp.microsoft.com>
	<20130204234208.GA25210@matrix.chaos.earth.li>
	<CAJumaK8bH3=VbZQORxcFA0RyGGCeoRb1ieDJVempr8Wi7BVnMw@mail.gmail.com>
	<20130205134247.GA9486@matrix.chaos.earth.li>
Message-ID: <CAJumaK_PR1+jFdSvZypEUN07GQpMzKMEt4YTMEMMEFzAK=LiYQ@mail.gmail.com>

On the topic of liberalizing operators that are currently only used in
patterns, another one that would be amazing to have as a valid term (or
type operator) is @ using similar () tricks. 1 character operator names are
in dreadful short supply and really help make nice DSLs.

-Edward

On Tue, Feb 5, 2013 at 8:42 AM, Ian Lynagh <ian at well-typed.com> wrote:

> On Mon, Feb 04, 2013 at 07:26:16PM -0500, Edward Kmett wrote:
> > If space sensitivity or () disambiguation is being used on !, could one
> of
> > these also be permitted on ~ to permit it as a valid infix term-level
> > operator?
>
> I don't think there's any reason ~ couldn't be an operator, defined with
> the
>     (~) x y = ...
> syntax.
>
> Allowing it to be defined with infix syntax would be a little trickier.
>
>
> Hmm, I've just realised that if we decide to make !_ and !foo lexemes,
> then we'd also want !(+) to be a lexeme, which presumably means we'd
> want (+) to be a single lexeme too (and also `foo`, for consistency).
> But I don't think making that change would be problematic.
>
>
> Thanks
> Ian
>
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-prime/attachments/20130205/a082b1fb/attachment.htm>

From marlowsd at gmail.com  Thu Feb  7 13:24:48 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 07 Feb 2013 12:24:48 +0000
Subject: Bang patterns
In-Reply-To: <20130204234208.GA25210@matrix.chaos.earth.li>
References: <20130201171042.GA7743@matrix.chaos.earth.li>
	<20130203223404.GA24375@euler.dow.cam.ac.uk>
	<20130203232212.GA22702@matrix.chaos.earth.li>
	<20130204004453.GE29536@euler.dow.cam.ac.uk>
	<20130204012018.GA24206@matrix.chaos.earth.li>
	<59543203684B2244980D7E4057D5FBC147726CC4@DB3EX14MBXC312.europe.corp.microsoft.com>
	<20130204234208.GA25210@matrix.chaos.earth.li>
Message-ID: <51139D10.4030709@gmail.com>

On 04/02/13 23:42, Ian Lynagh wrote:
> On Mon, Feb 04, 2013 at 10:37:44PM +0000, Simon Peyton-Jones wrote:
>>
>> I don't have a strong opinion about whether
>> 	f ! x y ! z = e
>> should mean the same; ie whether the space is significant.   I think it's probably more confusing if the space is significant (so its presence or absence makes a difference).
>
> I also don't feel strongly, although I lean the other way:
>
> I don't think anyone writes "f ! x" when they mean "f with a strict
> argument x", and I don't see any particular advantage in allowing it.
> In fact, I think writing that is less clear than "f !x", so there is an
> advantage in disallowing it.
>
> It also means that existing code that defines a (!) operator in infix
> style would continue to work, provided it puts whitespace around the !.

FWIW, I really dislike whitespace-significant syntax.  f ! x should mean 
the same as f !x.  Look at the trouble we have with qualified operators: 
how many people have tried to write [Monday..] and been surprised that 
it doesn't work?

So I don't mind at all if BangPatterns makes it harder to write a 
definition of '!', because it's much more common to write bang patterns 
than it is to define '!', and the workaround of writing (!) is not that 
onerous.

Aside from preferring not to change the lexical syntax, I don't have a 
strong opinion. Your original third option, treating ! and ~ the same 
way, looks ok to me, but I also like the idea of only allowing bang 
patterns where they make sense (variables and pattern bindings).

Cheers,
	Simon



From atze at uu.nl  Thu Feb  7 15:25:51 2013
From: atze at uu.nl (Atze Dijkstra)
Date: Thu, 7 Feb 2013 15:25:51 +0100
Subject: Bang patterns
In-Reply-To: <51139D10.4030709@gmail.com>
References: <20130201171042.GA7743@matrix.chaos.earth.li>
	<20130203223404.GA24375@euler.dow.cam.ac.uk>
	<20130203232212.GA22702@matrix.chaos.earth.li>
	<20130204004453.GE29536@euler.dow.cam.ac.uk>
	<20130204012018.GA24206@matrix.chaos.earth.li>
	<59543203684B2244980D7E4057D5FBC147726CC4@DB3EX14MBXC312.europe.corp.microsoft.com>
	<20130204234208.GA25210@matrix.chaos.earth.li>
	<51139D10.4030709@gmail.com>
Message-ID: <1D63D741-B897-420D-AA74-13AB33E2BA8A@uu.nl>


On  7 Feb, 2013, at 13:24 , Simon Marlow <marlowsd at gmail.com> wrote:

> On 04/02/13 23:42, Ian Lynagh wrote:
>> On Mon, Feb 04, 2013 at 10:37:44PM +0000, Simon Peyton-Jones wrote:
>>> 
>>> I don't have a strong opinion about whether
>>> 	f ! x y ! z = e
>>> should mean the same; ie whether the space is significant.   I think it's probably more confusing if the space is significant (so its presence or absence makes a difference).
>> 
>> I also don't feel strongly, although I lean the other way:
>> 
>> I don't think anyone writes "f ! x" when they mean "f with a strict
>> argument x", and I don't see any particular advantage in allowing it.
>> In fact, I think writing that is less clear than "f !x", so there is an
>> advantage in disallowing it.
>> 
>> It also means that existing code that defines a (!) operator in infix
>> style would continue to work, provided it puts whitespace around the !.
> 
> FWIW, I really dislike whitespace-significant syntax.  f ! x should mean the same as f !x.  Look at the trouble we have with qualified operators: how many people have tried to write [Monday..] and been surprised that it doesn't work?
> 
> So I don't mind at all if BangPatterns makes it harder to write a definition of '!', because it's much more common to write bang patterns than it is to define '!', and the workaround of writing (!) is not that onerous.
> 

I agree, I prefer the invariant that lexically whitespace does not matter. It is easier to understand, implement, and it is not such a big deal to have the choice of meaning (i.e. bang pattern or infix operator) depend on a LANGUAGE pragma, (re)defining ! is not that common anyway.

cheers,


               - Atze -

Atze Dijkstra, Department of Information and Computing Sciences. /|\
Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \
Tel.: +31-30-2534118/1454 | WWW  : http://www.cs.uu.nl/~atze . /--|  \
Fax : +31-30-2513971 .... | Email: atze at uu.nl ............... /   |___\





From haskell at benmachine.co.uk  Fri Feb  8 12:49:59 2013
From: haskell at benmachine.co.uk (Ben Millwood)
Date: Fri, 8 Feb 2013 11:49:59 +0000
Subject: Bang patterns
In-Reply-To: <51139D10.4030709@gmail.com>
References: <20130201171042.GA7743@matrix.chaos.earth.li>
	<20130203223404.GA24375@euler.dow.cam.ac.uk>
	<20130203232212.GA22702@matrix.chaos.earth.li>
	<20130204004453.GE29536@euler.dow.cam.ac.uk>
	<20130204012018.GA24206@matrix.chaos.earth.li>
	<59543203684B2244980D7E4057D5FBC147726CC4@DB3EX14MBXC312.europe.corp.microsoft.com>
	<20130204234208.GA25210@matrix.chaos.earth.li>
	<51139D10.4030709@gmail.com>
Message-ID: <20130208114958.GA1322@euler.maths.private.cam.ac.uk>

On Thu, Feb 07, 2013 at 12:24:48PM +0000, Simon Marlow wrote:
>FWIW, I really dislike whitespace-significant syntax.  f ! x should 
>mean the same as f !x.  Look at the trouble we have with qualified 
>operators: how many people have tried to write [Monday..] and been 
>surprised that it doesn't work?

What about `elem`? I don't think anyone would argue that ` elem ` makes 
sense.


From marlowsd at gmail.com  Fri Feb  8 13:27:41 2013
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 08 Feb 2013 12:27:41 +0000
Subject: Bang patterns
In-Reply-To: <20130208114958.GA1322@euler.maths.private.cam.ac.uk>
References: <20130201171042.GA7743@matrix.chaos.earth.li>
	<20130203223404.GA24375@euler.dow.cam.ac.uk>
	<20130203232212.GA22702@matrix.chaos.earth.li>
	<20130204004453.GE29536@euler.dow.cam.ac.uk>
	<20130204012018.GA24206@matrix.chaos.earth.li>
	<59543203684B2244980D7E4057D5FBC147726CC4@DB3EX14MBXC312.europe.corp.microsoft.com>
	<20130204234208.GA25210@matrix.chaos.earth.li>
	<51139D10.4030709@gmail.com>
	<20130208114958.GA1322@euler.maths.private.cam.ac.uk>
Message-ID: <5114EF3D.8020301@gmail.com>

On 08/02/13 11:49, Ben Millwood wrote:
> On Thu, Feb 07, 2013 at 12:24:48PM +0000, Simon Marlow wrote:
>> FWIW, I really dislike whitespace-significant syntax.  f ! x should
>> mean the same as f !x.  Look at the trouble we have with qualified
>> operators: how many people have tried to write [Monday..] and been
>> surprised that it doesn't work?
>
> What about `elem`? I don't think anyone would argue that ` elem ` makes
> sense.

Prelude> 1 ` elem ` [1..10]
True
Prelude> 1 ` {- comment -} elem ` [1..10]
True

backticks are part of the context-free syntax, not the lexical syntax 
(as they should be!).  I'm of the opinion that the lexical syntax should 
be as simple, and as far as possible everything should be pushed into 
the context-free syntax.

Cheers,
	Simon



From doaitse at swierstra.net  Fri Feb  8 14:23:43 2013
From: doaitse at swierstra.net (Doaitse Swierstra)
Date: Fri, 8 Feb 2013 14:23:43 +0100
Subject: Bang patterns
In-Reply-To: <5114EF3D.8020301@gmail.com>
References: <20130201171042.GA7743@matrix.chaos.earth.li>
	<20130203223404.GA24375@euler.dow.cam.ac.uk>
	<20130203232212.GA22702@matrix.chaos.earth.li>
	<20130204004453.GE29536@euler.dow.cam.ac.uk>
	<20130204012018.GA24206@matrix.chaos.earth.li>
	<59543203684B2244980D7E4057D5FBC147726CC4@DB3EX14MBXC312.europe.corp.microsoft.com>
	<20130204234208.GA25210@matrix.chaos.earth.li>
	<51139D10.4030709@gmail.com>
	<20130208114958.GA1322@euler.maths.private.cam.ac.uk>
	<5114EF3D.8020301@gmail.com>
Message-ID: <4A1FF385-04B0-4756-89CB-CB63D6E4DB86@swierstra.net>

I prefer them to be part of the context-free syntax, since this enables a future extension in which an arbitary expression can be placed between backticks. This would enable one to write things as:

 x `f i` y

and

expr1 `expr2` expr3 


is to be interpreted as (expr2) (expr1) (expr3),

 Doaitse




 


On Feb 8, 2013, at 13:27 , Simon Marlow <marlowsd at gmail.com>
 wrote:

> On 08/02/13 11:49, Ben Millwood wrote:
>> On Thu, Feb 07, 2013 at 12:24:48PM +0000, Simon Marlow wrote:
>>> FWIW, I really dislike whitespace-significant syntax.  f ! x should
>>> mean the same as f !x.  Look at the trouble we have with qualified
>>> operators: how many people have tried to write [Monday..] and been
>>> surprised that it doesn't work?
>> 
>> What about `elem`? I don't think anyone would argue that ` elem ` makes
>> sense.
> 
> Prelude> 1 ` elem ` [1..10]
> True
> Prelude> 1 ` {- comment -} elem ` [1..10]
> True
> 
> backticks are part of the context-free syntax, not the lexical syntax (as they should be!).  I'm of the opinion that the lexical syntax should be as simple, and as far as possible everything should be pushed into the context-free syntax.
> 
> Cheers,
> 	Simon
> 
> 
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime