2025/09/11

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 +0200petrichor(~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 +0200petrichor(~jez@user/petrichor) petrichor
2025-09-11 11:46:49 +0200LainIwakura(~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 +0200petrichor(~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 +0200petrichor(~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 +0200ridcully(~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 +0200tromp(~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 +0200segfaultfizzbuzz(~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 +0200skialso 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