#6026: Unboxed operators have wrong fixity
+---
Reporter: benl | Owner: igloo
Type: bug | Status: patch
#6026: Unboxed operators have wrong fixity
--+-
Reporter: benl | Owner: igloo
Type: bug | Status: closed
#6026: Unboxed operators have wrong fixity
+---
Reporter: benl | Owner:
Type: bug | Status: patch
#6026: Unboxed operators have wrong fixity
+---
Reporter: benl | Owner: igloo
Type: bug | Status: patch
#6026: Unboxed operators have wrong fixity
+---
Reporter: benl | Owner:
Type: bug | Status: new
wren ng thornton wren at freegeek.org writes:
As for whether the default should be infix 9 instead of infixl 9 ...
that was exactly the point of my message. - J.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On 12-10-06 05:18 AM, Johannes Waldmann wrote:
wren ng thornton wren at freegeek.org writes:
As for whether the default should be infix 9 instead of infixl 9 ...
that was exactly the point of my message. - J.
Perhaps, half of the people want infixl, another half of the people want
infixr,
a fixity declaration
is assumed to be infixl 9. This really should be infix 9?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
) or they are undefined, so the parser rejects.
but the Haskell standard says Any operator lacking a fixity declaration
is assumed to be infixl 9. This really should be infix 9?
This behaviour is really handy when you use functions as operators
(using backticks notation). They typically lack infix
rejects.
but the Haskell standard says Any operator lacking a fixity declaration
is assumed to be infixl 9. This really should be infix 9?
This behaviour is really handy when you use functions as operators
(using backticks notation). They typically lack infix annotations, but
having to put
, I'm profoundly glad
that Haskell doesn't do this. The fixity of an operator is a property of
the operator itself, not of the notation used to display the operator.
There's no reason for my (+) operator to have the same fixity as your
(+) operator, regardless of whether we happen to use the same
Your idea looks _much_ better from code clarity point of view, but it's
unclear to me, how to deal with it internally and in error messages. I'm
not a compiler guy, though.
Worse, it does not allow to set up fixity relative to operator that is
not in scope and it will create unnecessary
is pretty weak, however; even the lip service paid to unary - is a
source of many problems in parsing Haskell.
Worse, it does not allow to set up fixity relative to operator that is not
in scope and it will create unnecessary intermodule dependencies. One
should fall back to numeric fixities
can guess it. This way. however, is linearly dependent in time
from number of operators in scope. It is clearly much worse then looking
into Map OperatorName Fixity . But changing numeric fixity in Map when
adding operator somewhere in between existing stack is also linearly -
dependent
AntC anthony_clay...@clear.net.nz writes:
I agree. I don't declare operators very often, and when I do I always
struggle
to remember which way round the precedence numbers go.
[...]
(Anything else we can bikeshed about while we're at it?)
infixl * before +
Perhaps before and after
would suffice if the default was for operators to be non-fix and
of indeterminate precedence. Multiple fixity declarations for the same operator
should then be allowed. Or perhaps just require that separate declarations use
the same infix[lr]? keyword.
Twan
also separate precedence from fixity declaration
precedence $ below +
-- function application has higher precedence than all operators by
default, but you can override that
infixl . above APP
-- == is non-associative
infix ==
Here's some parses with this system:
a + b - c = (a+b)-c
f.x.y z == g
aiming for, then copy
its definition. It would be much easier to declare the fixity of myop to be
same as someotherop (which would presumably have to be already declared/fixed
in an imported module).
[It's also slightly counterintuitive that the thing being defined comes last
in an infix
fixity declaration has form *infix(l|r)? [Digit]* in haskell. I'm pretty
sure, that this is not enough for complicated cases. Ideally, fixity
declarations should have form *infix(l|r)? [Digit](\.(+|-)[Digit])** ,
with implied infinitely long repeated (.0) tail. This will allow fine
tuning
#7007: Fixity declaration reported as ambiguous
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal
#6091: Fixity in :info for backticks operators
-+--
Reporter: guest | Owner: pcapriotti
Type: bug | Status: new
Priority: normal
#6091: Fixity in :info for backticks operators
---+
Reporter: guest | Owner: pcapriotti
Type: bug | Status: closed
Priority: normal
#6091: Fixity in :info for backticks operators
--+-
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal
#6091: Fixity in :info for backticks operators
-+--
Reporter: guest | Owner: pcapriotti
Type: bug | Status: new
Priority: normal
#6027: Allow changing fixity of new type operators
-+--
Reporter: atnnn | Owner: pcapriotti
Type: feature request | Status: patch
Priority: normal
#6027: Allow changing fixity of new type operators
-+--
Reporter: atnnn | Owner: pcapriotti
Type: feature request | Status: patch
Priority: normal
#6027: Allow changing fixity of new type operators
-+--
Reporter: atnnn | Owner: pcapriotti
Type: feature request | Status: patch
Priority: normal
#6027: Allow changing fixity of new type operators
-+--
Reporter: atnnn | Owner: pcapriotti
Type: feature request | Status: patch
Priority: normal
#6027: Allow changing fixity of new type operators
---+
Reporter: atnnn | Owner: pcapriotti
Type: feature request | Status: closed
Priority: normal
#6027: Allow changing fixity of new type operators
-+--
Reporter: atnnn | Owner: pcapriotti
Type: feature request | Status: patch
Priority: normal
#6027: Allow changing fixity of new type operators
-+--
Reporter: atnnn | Owner: pcapriotti
Type: feature request | Status: new
Priority: normal
#6026: Unboxed operators have wrong fixity
-+--
Reporter: benl | Owner:
Type: bug | Status: new
Priority: normal
#6027: Allow changing fixity of new type operators
--+-
Reporter: atnnn | Owner:
Type: feature request | Status: new
Priority: normal
#6026: Unboxed operators have wrong fixity
-+--
Reporter: benl | Owner:
Type: bug | Status: new
Priority: normal
#6026: Unboxed operators have wrong fixity
-+--
Reporter: benl | Owner:
Type: bug | Status: new
Priority: normal
#1541: No way at all to set fixity for infix operators defined in template
haskell
---+
Reporter: guest | Owner: reinerp
Type: bug | Status: closed
#1541: No way at all to set fixity for infix operators defined in template
haskell
-+--
Reporter: guest | Owner: reinerp
Type: bug | Status: new
#1541: No way at all to set fixity for infix operators defined in template
haskell
---+
Reporter: guest | Owner: reinerp
Type: bug | Status: closed
#1541: No way at all to set fixity for infix operators defined in template
haskell
-+--
Reporter: guest | Owner: reinerp
Type: bug | Status: new
#1541: No way at all to set fixity for infix operators defined in template
haskell
-+--
Reporter: guest | Owner: reinerp
Type: bug | Status: new
guess is that is infixl because
(1) m = f = g should make sense
(2) should match fixity and precedence with =
On Tue, Feb 14, 2012 at 9:50 PM, Michael Baikov manpac...@gmail.com wrote:
Most docs ([1], [2]) about do-notation syntactic sugar tends to
describe following expressions as equivalent
Most docs ([1], [2]) about do-notation syntactic sugar tends to
describe following expressions as equivalent:
do { a; b; c } and a b c, but they are not: first one gets
de-sugared into a (b c), second one is equivalent to (a
b) c, because () is declared using infixl.
This should not be
Hello everyone,
while I'm playing with fixity declaration in GHCi, I found a strange
behavior. Can anyone explain this?
Is this actually an expected behavior, or is it a glitch?
$ ghci
GHCi, version 7.0.3: http://www.haskell.org
#1541: No way at all to set fixity for infix operators defined in template
haskell
-+--
Reporter: guest |Owner: reinerp
Type: bug | Status: new
#1541: No way at all to set fixity for infix operators defined in template
haskell
-+--
Reporter: guest |Owner: reinerp
Type: bug | Status: new
#4180: do not consider associativity for unary minus for fixity resolution
--+-
Reporter: maeder |Owner:
Type: feature request| Status: new
Priority
#4180: do not consider associativity for unary minus for fixity resolution
--+-
Reporter: maeder |Owner:
Type: proposal | Status: new
Priority
#4180: do not consider associativity for unary minus for fixity resolution
--+-
Reporter: maeder |Owner:
Type: proposal | Status: new
Priority
#4180: do not consider associativity for unary minus for fixity resolution
--+-
Reporter: maeder |Owner:
Type: proposal | Status: new
Priority
#4180: do not consider associativity for unary minus for fixity resolution
--+-
Reporter: maeder |Owner:
Type: proposal | Status: new
Priority
#4180: do not consider associativity for unary minus for fixity resolution
--+-
Reporter: maeder |Owner:
Type: proposal | Status: new
Priority
#4180: do not consider associativity for unary minus for fixity resolution
--+-
Reporter: maeder |Owner:
Type: proposal | Status: new
Priority
#4180: do not consider associativity for unary minus for fixity resolution
-+--
Reporter: maeder| Owner:
Type: proposal | Status: new
Priority
#4180: do not consider associativity for unary minus for fixity resolution
-+--
Reporter: maeder| Owner:
Type: proposal | Status: new
Priority
fixity resolution is more strict than
it needs to be. The intention in Haskell 2010 was not to change the way
fixity resolution worked, but rather to avoid the problems caused by
having it as part of the grammar.
The grammar (in particular an ambiguous one) describes a superset of the
language
Christian Maeder schrieb:
http://www.haskell.org/~simonmar/haskell-2010-draft-report-2/haskellch10.html#x17-17300010
Fixity resolution also applies to Haskell patterns, but patterns are a
subset of expressions so in what follows we consider only expressions
for simplicity.
I suggest
also:
http://hackage.haskell.org/trac/ghc/ticket/4176
Christian
Furthermore fixity resolution does not distinguish between constructors
and other operators as it should according to the grammar:
pat → lpat qconop pat (infix constructor)
| lpat
funlhs
)!
1 * - 1 = 2
Main 1 Main.* (-1)
2
Well, that's a bug in GHC, not the Haskell report :-)
see also:
http://hackage.haskell.org/trac/ghc/ticket/4176
Thanks for reporting it.
Cheers,
Simon
Christian
Furthermore fixity resolution does not distinguish between constructors
associativity
- 1 ## 2 ~~~ (-1) ## 2
Yes, again I agree. The current fixity resolution is more strict than
it needs to be. The intention in Haskell 2010 was not to change the way
fixity resolution worked, but rather to avoid the problems caused by
having it as part of the grammar.
The grammar
http://www.haskell.org/~simonmar/haskell-2010-draft-report-2/haskellch10.html#x17-17300010
Fixity resolution also applies to Haskell patterns, but patterns are a
subset of expressions so in what follows we consider only expressions
for simplicity.
The string 1 * - 1 is legal as pattern
let me try again to fix the issue. Apologies, if you mind.
Christian Maeder schrieb:
S. Doaitse Swierstra schrieb:
weird :: Int - Int
weird = (if True then 3 else 5+)
is perfectly correct Haskell?
Yes, this is legal according to the grammar
http://haskell.org/onlinereport/syntax-iso.html
S. Doaitse Swierstra schrieb:
weird :: Int - Int
weird = (if True then 3 else 5+)
is perfectly correct Haskell?
Yes, this is legal according to the grammar
http://haskell.org/onlinereport/syntax-iso.html
but rejected by ghc and hugs, because 5+ is illegal.
The problem is to allow let-, if-,
Christian Maeder schrieb:
S. Doaitse Swierstra schrieb:
weird :: Int - Int
weird = (if True then 3 else 5+)
[...]
infixexp - fexp qop infixexp
| exp10
This is no good, because it would exclude:
do ...
++ do
expressions.
It would be even possible to avoid parenthesis
#1541: No way at all to set fixity for infix operators defined in template
haskell
-+--
Reporter: guest |Owner:
Type: bug | Status: new
It turns out that there is at least a (partial) solution to my
quasiquote problem. Template Haskell's reify function can be used to
find an operator's fixity, although it seems not for all cases.
However, for the purposes of this discussion, suppose I can write a
function
userFixity :: String - Q
of the fixities, so that I can insert the correct ones
there. For this use case, I would want HSE to use an AST like I
suggested, because it allows the parser to say, I'm not sure what the
correct fixity is.
As noted above, I really don't like that change. If you use HSE for
parsing expressions
it unsure of the fixities, so that I can insert the correct ones
there. For this use case, I would want HSE to use an AST like I
suggested, because it allows the parser to say, I'm not sure what the
correct fixity is.
As noted above, I really don't like that change. If you use HSE for
parsing
with the fixity fixing. However...
I would also like to point out that a list representation as I
suggested can in fact encode the correct fixities if they are known to
HSE. This is true simply because the list constructor is isomorphic to
the current constructor in the special case where the list
what uses you envision and
how it would be made easier. I'm still in the process of designing the
fixity support for HSE, and all input is valuable. :-)
Cheers,
/Niklas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman
It seems to me that fixity information behaves more like semantics
than like syntax. For instance, fixities may be imported, and obey
namespacing rules. Knowing and correctly handling these rules seems
beyond the scope of a mere parser: I would hope that a single Haskell
file could be parsed
operators, (+*) and (+^), and then write
[$list|1+*2+^3|]
Being able to correctly parse such an expression depends on known the
two operator's fixities, which is currently impossible. The problem is
that potentially non-local fixity declarations affect parsing.
As far as I can see, the correct
on known the
two operator's fixities, which is currently impossible. The problem is
that potentially non-local fixity declarations affect parsing.
As far as I can see, the correct solution is to change the Template
Haskell AST representation of fixity expressions from
data Exp = ...
| InfixE
#2632: Template Haskell confused by operator fixity
--+-
Reporter: simonpj | Owner: igloo
Type: merge | Status: closed
Priority: normal
#2632: Template Haskell confused by operator fixity
--+-
Reporter: simonpj | Owner: igloo
Type: merge | Status: new
Priority: normal
#2632: Template Haskell confused by operator fixity
-+--
Reporter: simonpj | Owner: simonpj
Type: bug | Status: new
Priority: normal| Milestone: 6.10.1
Component
#2632: Template Haskell confused by operator fixity
--+-
Reporter: simonpj | Owner: simonpj
Type: bug | Status: new
Priority: normal| Milestone: 6.10.1
Component: Compiler
#1541: No way at all to set fixity for infix operators defined in template
haskell
-+--
Reporter: guest |Owner:
Type: bug | Status: new
Priority: normal
ross:
On Fri, Jul 27, 2007 at 12:08:30AM +1000, Donald Bruce Stewart wrote:
There's a theory this should work:
getContents = lines map read sum print
But unfortunately we have:
`(=)' [infixl 1]
`()' [infixr 1]
Meaning we must write:
getContents =
On Fri, Jul 27, 2007 at 12:08:30AM +1000, Donald Bruce Stewart wrote:
There's a theory this should work:
getContents = lines map read sum print
But unfortunately we have:
`(=)' [infixl 1]
`()' [infixr 1]
Meaning we must write:
getContents = (lines map read
There's a theory this should work:
getContents = lines map read sum print
But unfortunately we have:
`(=)' [infixl 1]
`()' [infixr 1]
Meaning we must write:
getContents = (lines map read sum print)
Indeed, all Arrow ops are infixr.
Are there any technical/compelling
#1541: No way at all to set fixity for infix operators defined in template
haskell
-+--
Reporter: guest |Owner:
Type: bug | Status: new
Priority: normal
#1541: No way to set build fixity declarations in template haskell
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone
#1541: No way at all to set fixity for infix operators defined in template
haskell
-+--
Reporter: guest |Owner:
Type: bug | Status: new
Priority: normal
Hello Isaac,
Monday, June 18, 2007, 9:20:29 PM, you wrote:
I was just bitten in ghci by `divMod` being the default infixl 9 instead
of the same as `div` and `mod`.
one of my hard-to-find bugs was exactly in this area: i wrote
something like x `div` y+1 instead of x `div` (y+1)
so, based
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I was just bitten in ghci by `divMod` being the default infixl 9 instead
of the same as `div` and `mod`. Sure enough, the standard prelude
doesn't specify a fixity for `quotRem` and `divMod` even though `quot`,
`rem`, `div`, and `mod` are all infixl
by `divMod` being the default infixl 9 instead
of the same as `div` and `mod`. Sure enough, the standard prelude
doesn't specify a fixity for `quotRem` and `divMod` even though `quot`,
`rem`, `div`, and `mod` are all infixl 7. I propose that `quotRem` and
`divMod` also become infixl 7.
Isaac
-BEGIN
Twan van Laarhoven wrote:
Add subsection:
=== 3.4.1 Fixity Resolution ===
Fixity resolution is applied after parsing to convert all operator
applications to the form @e1 qop [EMAIL PROTECTED]
Fixity resolution is specified by the following algorithm:
Let $e$ be an expression anywhere
[EMAIL PROTECTED] wrote:
I think that computable real fixity levels are useful, too.
Only finitely many operators can be declared in a given Haskell program.
Thus the strongest property you need in your set of precedence levels is
that given arbitrary finite sets of precedences A and B
I'm surprised that no one has mentioned showsPrec and readsPrec. Anything
more complicated than negative fixities would require their interfaces to be
changed.
-- Ben
___
Haskell-prime mailing list
Haskell-prime@haskell.org
On Fri, 10 Nov 2006, Ben Rudiak-Gould wrote:
I'm surprised that no one has mentioned showsPrec and readsPrec. Anything more
complicated than negative fixities would require their interfaces to be
changed.
Very true. Does it mean, that the Functional Graph Library has to become
part of the
On Fri, 10 Nov 2006, Benjamin Franksen wrote:
Although one could view this as a bug in the offending module it makes
me somewhat uneasy that one additional import can have such a drastic
effect on the code in a module /even if you don't use anything from that
module/.
It's the same as with
Henning Thielemann wrote:
On Fri, 10 Nov 2006, Benjamin Franksen wrote:
Although one could view this as a bug in the offending module it makes
me somewhat uneasy that one additional import can have such a drastic
effect on the code in a module /even if you don't use anything from that
On Nov 9, 2006, at 7:16 PM, Benjamin Franksen wrote:
Carl Witty wrote:
On Thu, 2006-11-09 at 22:20 +0100, Benjamin Franksen wrote:
Henning Thielemann wrote:
Maybe making fixity declarations like type class instance
declarations
is
good.
I thought so too at first but, having thought
Jan-Willem Maessen wrote:
On Nov 9, 2006, at 7:16 PM, Benjamin Franksen wrote:
Carl Witty wrote:
If you have operators op1 and op2, where the compiler sees
conflicting
requirements for the precedence of op1 and op2, then they are
treated as
non-associative relative to each other: the
I'm surprised that no one has mentioned showsPrec and readsPrec. Anything
more complicated than negative fixities would require their interfaces to be
changed.
-- Ben
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
more) are a lot better than
precedence numbers, whether they be fractional or integral.
Let us add compiler/interpreter support for querying known precedence/fixity
relations and it's (almost) perfect.
Cheers
Ben
___
Haskell-prime mailing list
Haskell
between (==) and (+).
Yes, presumably. However, currently a fixity declaration for an
operator can only be given in the module where the operator is
defined. In this hypothetical new system, how would one import/export
fixity declarations? Should they be named, or should they be treated
like
* backticks for operators with function names can be left out)
Fixity would have to be declared separately as (using 'infixl' or 'infixr';
or whatever).
Whenever we would currently declare an operator as having precedence N, we'd
now declare it to have precedence equal to one or more operators from
more) are a lot better than
precedence numbers, whether they be fractional or integral.
Let us add compiler/interpreter support for querying known precedence/fixity
relations and it's (almost) perfect.
Cheers
Ben
___
Haskell-Cafe mailing list
Haskell-Cafe
Henning Thielemann wrote:
Maybe making fixity declarations like type class instance declarations is
good.
I thought so too at first but, having thought about it for a while, I now
see this will cause /major/ problems. The precedence relations as declared
explicitly by the programmer must form
1 - 100 of 189 matches
Mail list logo
