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 08/02/13 11:49, Ben Millwood wrote:
On Thu, Feb 07, 2013 at 12:24:48PM +, 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..] an
On Thu, Feb 07, 2013 at 12:24:48PM +, 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?
e 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 wr
ant 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 '!
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
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
th
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 languag
On Mon, Feb 04, 2013 at 01:21:31PM -0800, Johan Tibell wrote:
On Sun, Feb 3, 2013 at 4:44 PM, Ben Millwood 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
On Mon, Feb 04, 2013 at 10:37:44PM +, 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
> abse
| > 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 th
On Sun, Feb 3, 2013 at 4:44 PM, Ben Millwood 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
On Mon, Feb 04, 2013 at 12:44:53AM +, 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
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
recognis
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 o
tal. 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
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
Brian Bloniarz wrote:
> I got confused by the GHC documentation recently, I was wondering how
> it could be improved. From:
> http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.html
Seeing the rule
pat ::= !pat
you'll probably want to avoid patterns like: "!!pat", "! ! pat", o
On Fri, Sep 07, 2007 at 09:24:51PM -0300, Isaac Dupree wrote:
> >Oh, and while we are at it, I think (:) should also be removed as a
> >reservedop, there is no reason for it to be on that list.
>
> Backwards compatibility requires that it be implicitly imported from
> Prelude even in a module th
Hi
Re ! as an operator: This caused a number of complexities in the
parsing of stuff, including shift-reduce conflicts. Someone would need
to look into this, and determine that the rules are completely
unambiguous.
> > Backwards compatibility requires that it be implicitly imported from
> > Prelu
Isaac Dupree wrote:
Twan van Laarhoven wrote:
Oh, and while we are at it, I think (:) should also be removed as a
reservedop, there is no reason for it to be on that list.
Backwards compatibility requires that it be implicitly imported from
Prelude even in a module that does "import Prelude (
Twan van Laarhoven wrote:
The bang pattern proposal [1] still allows (!) to be used as an
operator. I think there should be no difference in this regard between !
and ~, since they are used in exactly the same location.
In my opinion the best thing would be to allow (~) and (@) as operators.
reservedop -> .. | : | :: | = | \ | | | <- | -> | =>
Oh, and while we are at it, I think (:) should also be removed as a
reservedop, there is no reason for it to be on that list.
Twan
[1] Bang Patterns, Haskell-prime wiki
http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns
[2] Haskell 98 r
Simon Peyton-Jones wrote:
| What have you got in mind? ANY tupling of bindings may change the SCC
| structure, and hence the results of type inference--I'm taking that as
| read. But that still leaves the question of whether the dynamic
| semantics of the program is changed. Let's assume for the
| What have you got in mind? ANY tupling of bindings may change the SCC
| structure, and hence the results of type inference--I'm taking that as
| read. But that still leaves the question of whether the dynamic
| semantics of the program is changed. Let's assume for the time being
| that all bindin
Simon Peyton-Jones wrote:
I've updated the Wiki to add your strict proposal, but rather briefly.
If you want to add stuff, send it to me and I'll add it.
Meanwhile:
| And as a consequence, it is no longer possible to transform a pair of
| bindings into a binding of a pair. In Haskell 98,
|
|
I've updated the Wiki to add your strict proposal, but rather briefly.
If you want to add stuff, send it to me and I'll add it.
Meanwhile:
| And as a consequence, it is no longer possible to transform a pair of
| bindings into a binding of a pair. In Haskell 98,
|
| p1 = e1
| p2 = e2
|
and after that it's all just standard
Haskell 98.
My summary so far:
Good summary.
1) Bang patterns by themselves are quite decent, well-behaved patterns.
2) Rule (P1) is simple to describe. But the ! in a pattern binding is
treated as part of the *binding* rather than part of the *pa
#x27;s all just standard
Haskell 98.
My summary so far:
1) Bang patterns by themselves are quite decent, well-behaved patterns.
2) Rule (P1) is simple to describe. But the ! in a pattern binding is
treated as part of the *binding* rather than part of the *pattern* which
is wart-y.
3) There is a good
From: Simon Peyton-Jones
To: John Hughes ; haskell-prime@haskell.org
Sent: Tuesday, February 07, 2006 11:37 PM
Subject: RE: Bang patterns, ~ patterns, and lazy let
Applying the rules on the wiki, the first step is to translate the first
expression into a tuple binding, omitting the
Applying the rules on the wiki, the first step is to
translate the first _expression_ into a tuple binding, omitting the implicit ~:
Not so! I changed it a few days ago
after talking to Ben, to a simpler form that works nicely for recursive
bindings too. Darn – I forgot to change th
From: Ben Rudiak-Gould <[EMAIL PROTECTED]>
Subject: Re: Bang patterns, ~ patterns, and lazy let
It's also not that case that !x has the same
meaning in both proposals, e.g.
let { !x = y ; !y = const 'a' x } in x
means 'a' in the current propo
John Hughes wrote:
* ! on the left hand side of a let or where *has a different meaning to !
in a pattern* -- it means that the ~ that would have been implicitly
inserted by the previous rule, is not inserted after all!
I wish it were that simple, but I don't think it is.
let { !x = const
From: Ross Paterson <[EMAIL PROTECTED]>
John Hughes wrote:
I would urge that either we stick with the present design, or, if bang
patterns are added (which a lot speaks for), that the language be
simplified at the same time so that patterns are matched in the same way
everywher
On Tue, Feb 07, 2006 at 09:02:36AM +0100, John Hughes wrote:
> I would urge that either we stick with the present design, or, if bang
> patterns are added (which a lot speaks for), that the language be
> simplified at the same time so that patterns are matched in the same way
> eve
urge that either we stick with the present design, or, if bang
patterns are added (which a lot speaks for), that the language be
simplified at the same time so that patterns are matched in the same way
everywhere, and BOTH warts above are excised. Some existing code would
break, but in return
Pursuant to a recent conversation with Simon, my previous post to this
thread is now obsolete. So please ignore it, and see the updated wiki page
instead.
-- Ben
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/list
Simon Peyton-Jones wrote:
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/BangPatterns
You say that
let !(x, Just !y) = in
can't be desugared to
let
t =
x = case t of (x, Just !y) -> x
y = case t of (x, Just !y) -> y
in
t `seq`
and I agree
Earlier on the Haskell' list, I proposed bang patterns as a way to make
it more convenient for Haskell programmers to make their programs
stricter. E.g.
f (!x, y) =
I've documented the proposal here
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Ban
39 matches
Mail list logo
