Newest at the top
2025-09-11 11:53:40 +0200 | <ski> | mm yes, i should express that `p' is the intermediate operator, inbetween `o' and `q', here .. hmm |
2025-09-11 11:52:22 +0200 | <ski> | so, more generally, you could say `o B p C q' (where `o' is prefix and `q' suffix), then also `o B q' and `o C q' (assuming the associativity of both `B' and `C' is below that of `q' resp. `o') |
2025-09-11 11:52:15 +0200 | <tomsmeding> | (this is not about types, while the types differ here you could define operators with these precedences where all the types are the same) |
2025-09-11 11:51:37 +0200 | <tomsmeding> | (if I'm reading you correctly) |
2025-09-11 11:51:17 +0200 | <tomsmeding> | this rule is currently false in haskell |
2025-09-11 11:51:08 +0200 | <yahb2> | <interactive>:89:1: error: [GHC-88747] ; Precedence parsing error ; cannot mix ‘==’ [infix 4] and ‘==’ [infix 4] in the same infix expression |
2025-09-11 11:51:07 +0200 | <tomsmeding> | % 1 == 3 == 4 |
2025-09-11 11:51:02 +0200 | <yahb2> | False |
2025-09-11 11:51:02 +0200 | <tomsmeding> | % 1 == 2 && 3 == 4 |
2025-09-11 11:50:15 +0200 | petrichor | (~jez@user/petrichor) (Client Quit) |
2025-09-11 11:50:12 +0200 | <ski> | (note that `A o' there is basically a prefix operator, and `q D' a suffix operator) |
2025-09-11 11:49:39 +0200 | <ski> | having a prefix/suffix version of `(...)' (grouping) would violate this, btw, so that probably still ought to be an exception |
2025-09-11 11:48:20 +0200 | <ski> | this is a kind of abstract transitivity of precedences & associativity |
2025-09-11 11:47:35 +0200 | <ski> | also, if `A o B p C q D' is legal, where `o',`p',`q' are infix operators, and `A',`B',`C',`D' are atomic expressions (or expressions of less precedence than the respective adjacent operators), a useful rule to ponder having, would be that `A o B q D' and `A o C q D' also (ignoring types) ought to be legal |
2025-09-11 11:46:49 +0200 | petrichor | (~jez@user/petrichor) petrichor |
2025-09-11 11:46:49 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) (Quit: Client closed) |
2025-09-11 11:45:43 +0200 | <tomsmeding> | and usefully -- you get the same problem as we currently have with needing to depend on half of hackage just to give all the instances for your new fancy data type |
2025-09-11 11:45:14 +0200 | <tomsmeding> | but then that feels hard to usably accomplish in practice |
2025-09-11 11:44:58 +0200 | <tomsmeding> | an actual serious generalisation would be a precedence lattice |
2025-09-11 11:44:43 +0200 | <tomsmeding> | that sounds equivalent to numeric precedences, except for less names? |
2025-09-11 11:44:28 +0200 | petrichor | (~jez@user/petrichor) (Remote host closed the connection) |
2025-09-11 11:44:23 +0200 | <ski> | but you'd want to be able to declare precedence groups, and after-the-fact include more operators into existing groups |
2025-09-11 11:44:12 +0200 | petrichor | (~jez@user/petrichor) petrichor |
2025-09-11 11:44:03 +0200 | <tomsmeding> | Agda has fractional precedences |
2025-09-11 11:43:50 +0200 | <ski> | having non-numeric precedences would also be nice |
2025-09-11 11:43:50 +0200 | <tomsmeding> | and if you say + is commutative, sure, some other non-commutative operator :p |
2025-09-11 11:43:26 +0200 | <tomsmeding> | yes, versus `\x -> 1 + x + 2' |
2025-09-11 11:43:21 +0200 | ridcully | (~ridcully@p57b5234b.dip0.t-ipconnect.de) ridcully |
2025-09-11 11:43:18 +0200 | <ski> | ah, so `\x -> 1 + 2 + x' ? |
2025-09-11 11:43:15 +0200 | <tomsmeding> | and I presume they would remain possible with your proposal |
2025-09-11 11:43:08 +0200 | <tomsmeding> | with TupleSections both are already possible |
2025-09-11 11:43:00 +0200 | <tomsmeding> | yeah sorry I wrote tuples but I meant + |
2025-09-11 11:42:50 +0200 | tromp | (~textual@2001:1c00:3487:1b00:4ca2:8197:56e4:708) (Ping timeout: 245 seconds) |
2025-09-11 11:42:48 +0200 | <ski> | "where \x -> (1,2,x) can be a section" -- not with non-tuple sections |
2025-09-11 11:42:39 +0200 | <tomsmeding> | yours is more general than the current one, granted |
2025-09-11 11:42:15 +0200 | <ski> | mm |
2025-09-11 11:42:11 +0200 | <tomsmeding> | neither is fully general |
2025-09-11 11:41:58 +0200 | <tomsmeding> | I'm not sure your arbitrary line is better |
2025-09-11 11:41:49 +0200 | <tomsmeding> | currently there is also an arbitrary line: the partially-applied operator must be at the top level |
2025-09-11 11:41:47 +0200 | <ski> | i consider tuple sections to be a different animal than operator sections |
2025-09-11 11:41:27 +0200 | <ski> | yes |
2025-09-11 11:41:20 +0200 | <tomsmeding> | er, s/,/+/g |
2025-09-11 11:41:14 +0200 | <tomsmeding> | but then you're drawing an arbitrary line where \x -> (1,2,x) can be a section and \x -> (1,x,2) cannot |
2025-09-11 11:41:12 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 248 seconds) |
2025-09-11 11:40:26 +0200 | <ski> | people might start wanting `(0,(1,_),3)' to mean `\x -> (0,(1,x),3)' (rather than `(0,\x -> (1,x),3)'). the problem is one of delimitation, how far out does it "extend". if you insist on a missing operand at the start, or the end, with no extra syntax before/after those, that solves that issue |
2025-09-11 11:39:36 +0200 | <tomsmeding> | if not, then yes agda does that too |
2025-09-11 11:39:21 +0200 | <tomsmeding> | dminuoso: have you thought about combining mixfix with precedence and associativity |
2025-09-11 11:38:13 +0200 | ski | also would not be a fan of `_' for sections |
2025-09-11 11:38:02 +0200 | <tomsmeding> | in general though, GHC doesn't know anything about actual associativity of operators |
2025-09-11 11:37:44 +0200 | <tomsmeding> | because (.) is defined infixr |