Hello Don, Wednesday, April 16, 2008, 7:06:28 PM, you wrote:

In the list of features "required for Haskell in practice", bang patterns are way up there.

+1. they are also required to achieve good results in various shutouts :D -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hi

a!b = ...

Did I just define the function "a" or the function "!"?

I'm not saying they shouldn't be accepted, but the story should be a little clearer about this as well!

For what it is worth, in discussions with Matt, we wondered if eliminating infix function definition altogether was an option. We decided that you probably don't gain much by defining functions infix, as you have to define their type prefix anyway. Of course you still want to use functions infix, but that is a separate issue. Of course, this can't be done for Haskell', but might make an interesting alternative design. Thanks Neil

| > > In the list of features "required for Haskell in practice", bang patterns are | > > way up there. | > | > But their syntax has issues: | > | > a!b = ... | > | > Did I just define the function "a" or the function "!"? | | Interesting note, if we solve this, then we can apply the same thing to | the treatment of ~ and regain it as a usable operator. In GHC I implemented a pretty grotesque hack. I really really wanted f !x !y = e to work as you'd expect. But because of the infix operator thing, that parses as (f ! x) ! y = e A gruesome post-processing step restores the parse we want, for the special case of !. It's not nice, but I didn't have the luxury of changing anything else, which we do now. Not allowing infix functions on the LHS would be a notable simplification. Constructors in patterns should still be infix of course: f (a :=: b) = ... In any case, I've always thought this was weird: Just x == Just y = x == y Simon

| Just to clarify, issues of what names can be used for | type constructors aside, are you proposing dropping | infix syntax for defining functions, but retaining infix | syntax for defining types (and type families etc.)? | | Or would the last example have to be written | | data (+) a b = Left a | Right b I *am* proposing that varsyms become type *constructors* not type *variables*. I can see arguments both ways for allowing definitions in infix form, and I don't have a strong position either way. Simon

Am Freitag, 18. April 2008 11:54 schrieb Sittampalam, Ganesh:

Simon Peyton Jones wrote:

...

Not allowing infix functions on the LHS would be a notable simplification.

This would significantly weaken a useful property of Haskell, that definitions and uses often share the same concrete syntax. It's very natural to be able to define things that way and it would be a real shame to lose it (and I think it would break a lot of existing code).

+1 (f . g) x = f (g x) is really nice.

...

In any case, I've always thought this was weird: Just x == Just y = x == y

It takes a little getting used to, but I don't find it that weird.

+1

[…]

Best wishes, Wolfgang

John Meacham wrote:

On Fri, Apr 18, 2008 at 08:36:42AM +0100, Simon Peyton-Jones wrote:

...

Not allowing infix functions on the LHS would be a notable simplification. Constructors in patterns should still be infix of course: f (a :=: b) = ...

I don't know, I think this will confuse things, especially for newbies, people tend to say things like:

a + b = foo

as "a plus b is foo", and so would probably naturally write it in infix form, it would be a source of confusion if the compiler didn't accept it.

I don't think saying ~ and ! are operators unless they

1. immediately followed by a '(', a letter, or an underscore 2. are preceded by whitespace or BOL

is that onerous.

I don't like the idea of solving this in the lexical syntax, e.g. by the rules you gave above, it's just too ad-hoc. I think a better way to fix it is just to disallow infix declarations of !, ~ (and @ ?). Currently the grammar has: funlhs -> var apat {apat} | pati+1 varop(a,i) pati+1 | lpati varop(l,i) pati+1 | pati+1 varop(r,i) rpati | ( funlhs ) apat {apat} so we can use a restricted variant of varop that doesn't include !, ~ or @ (well, varop doesn't currently include ~ or @, but I assume we want it to - it would be similar to the way "hiding" is handled now). Incedentally I think we should use a different operator for array indexing, because ! is almost universally used to mean "strict" now: in bang patterns, strict datatype fields, and $!. See http://hackage.haskell.org/trac/haskell-prime/wiki/ArrayIndexing Cheers, Simon

Sittampalam, Ganesh wrote:

...

Incedentally I think we should use a different operator for array indexing, because ! is almost universally used to mean "strict" now: in bang patterns, strict datatype fields, and $!. See

...

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

A lot of the discussion on that page pre-supposes that CompositionAsDot will be accepted. Does it really stand a chance? It would be enormously disruptive and uglify the language massively. Making it necessary to use non-ASCII characters would be a big practical problem, I think.

Here are the possibilities for composition: 0. do nothing 1. use a Unicode operator for composition 2. require spaces around . as an operator 3. require spaces around all operators 4. use another ASCII operator for composition, e.g. <<< Nothing has been decided yet, but most of the committee tends to favour (2), with some expressing a slight preference for (0). We've pretty much ruled out (1) and (3) as too radical, and as you say using Unicode is still too impractical. There is some uncertainty about the precise details of (2), and thinking about that is what lead to my proposal about changing the syntax of qualified operators. Cheers, Simon

Am Dienstag, 22. April 2008 01:58 schrieb John Meacham:

[…]

There is also the proposal to change the fixity of '$'.

Why should the fixity of $ being changed? I thought, the reason for $ was that you can write a $ b $ c.

[…]

Best wishes, Wolfgang

Simon Marlow wrote:

Here are the possibilities for composition:

0. do nothing 1. use a Unicode operator for composition 2. require spaces around . as an operator 3. require spaces around all operators 4. use another ASCII operator for composition, e.g. <<<

Nothing has been decided yet, but most of the committee tends to favour (2), with some expressing a slight preference for (0). We've pretty much ruled out (1) and (3) as too radical, and as you say using Unicode is still too impractical.

There is some uncertainty about the precise details of (2), and thinking about that is what lead to my proposal about changing the syntax of qualified operators.

Ok, I'm going to try to make some progress on this. I think it's fair to say that the only possible options are (0) do nothing, or (2) require spaces around "." as an operator. I'll explore how we might do (2). We discussed this a bit on the committee mailing list, here's where we got to. The proposal amounts to making certain sequences illegal. Let's try to implement the informal rule dot is only allowed adjacent to a varid or conid when it is part of a qualified name so that would make these illegal: length.lines (.f) (f.) ++.x x.++ Just.(+1) Here's an interesting case: [Monday..Friday] which I imagine we would like to be legal. (currently it's illegal, or rather 'Monday..' is interpreted as a qualified operator; see separate proposal for changing the syntax of qualified operators). The way to implement this is to add the following productions to the lexical syntax: reservedlexeme ::= ({symbol} '.')<reservedop> (varid | conid) | (varid | conid) ('.' {symbol})<reservedop> The idea is that reservedlexemes are illegal, and work via the maximal-munch rule. (note that this version relies on the alternate qualified operator syntax proposal, because it makes the existing qualified operator syntax into a reservedlexeme). My personal view is that this is somewhat ugly. However, it does have the benefit of releasing the 'foo.x' syntax for future use, e.g. in a new record system - but some people find that a bit tasteless too, and I might be inclined to agree. Thoughts? Cheers, Simon

I don't think it makes sense to make a special case for requiring spaces around "$", as TH won't be in H'.

I agree, there's absolutely no need to treat $ differently in H'. The situation will already be better than it is now, since by the special treatment of . (and - and !, which I also agree with), there will be a precedent to follow (assuming it gets accepted of course). That alone makes it much easier to define the meaning of extensions like $ in TH. Cheers, /Niklas

On Tue, Apr 29, 2008 at 02:05:58PM -0700, Simon Marlow wrote:

that with the qualified operator change, this becomes:

f.g f . g (three tokens) F.g F.g (qualified `g') f.(.) f . (.) (three tokens) ***** F.(.) F.(.) (qualified `.') F. F . (two tokens)

And [f..], [F..] etc will parse as we want them to too. Sounds OK to me. Thanks Ian