Logs: liberachat/#haskell
| 2025-09-11 09:19:13 | <dminuoso> | If you want to tap into that, you need to special case the 1-tuple and it looks awkward |
| 2025-09-11 09:19:25 | <dminuoso> | (), Solo 1, (1, 2), (1, 2, 3) |
| 2025-09-11 09:19:27 | <dminuoso> | Just not pleasant. |
| 2025-09-11 09:19:43 | <dminuoso> | Besides, that Solo will not have sufficient instances across the ecosystem |
| 2025-09-11 09:21:03 | <lortabac> | overloaded parenthesis for both grouping and tuples is not ideal |
| 2025-09-11 09:21:41 | <dminuoso> | lortabac: python gets away syntactically by just having (1,) a 1-tuple |
| 2025-09-11 09:21:43 | <lortabac> | but it looks nice |
| 2025-09-11 09:21:58 | <dminuoso> | And since a trailing comma is allowed in general, it fits nicely in |
| 2025-09-11 09:22:12 | <lortabac> | dminuoso: that would be inconsistent with sections |
| 2025-09-11 09:22:20 | <dminuoso> | Indeed |
| 2025-09-11 09:22:20 | <lortabac> | (in Haskell) |
| 2025-09-11 09:22:26 | × | Rain quits (\@user/Rain-:22721) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-09-11 09:22:32 | → | Enrico63 joins (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) |
| 2025-09-11 09:23:01 | <dminuoso> | Personally I would have preferred an underscore for a section |
| 2025-09-11 09:23:07 | <dminuoso> | i.e. (1,_) |
| 2025-09-11 09:23:24 | <lortabac> | yes it's clearer |
| 2025-09-11 09:23:42 | <lortabac> | but at the same time things like (+ 1) are nice |
| 2025-09-11 09:24:04 | <lortabac> | tuple sections are good for consistency but probably not the best choice indeed |
| 2025-09-11 09:24:45 | <dminuoso> | Its always easy to critize these things in hindsight *after* 37 additional extensions have developed. |
| 2025-09-11 09:25:21 | <dminuoso> | Which underlines again the need for a time machine. |
| 2025-09-11 09:27:05 | <lortabac> | also, TBH the lack of singleton tuple is a very minor problem |
| 2025-09-11 09:27:09 | × | trickard_ quits (~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-09-11 09:27:22 | → | trickard_ joins (~trickard@cpe-54-98-47-163.wireline.com.au) |
| 2025-09-11 09:27:42 | <dminuoso> | Dunno, I like the consistency in these things. Im also a fan of having nullary typeclasses. |
| 2025-09-11 09:27:51 | × | Enrico63 quits (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 2025-09-11 09:29:01 | <dminuoso> | When working with things like postgresql-simple a singleton tuple would feel nice |
| 2025-09-11 09:30:55 | <tomsmeding> | dminuoso: typeclass machinery doesn't generalise over n-tuples at all |
| 2025-09-11 09:31:06 | <tomsmeding> | TemplateHaskell does, but as I showed above, that is aware of Solo |
| 2025-09-11 09:31:11 | <tomsmeding> | % $(pure $ TH.TupE [Just (TH.LitE (TH.IntegerL 42))]) |
| 2025-09-11 09:31:11 | <yahb2> | MkSolo 42 |
| 2025-09-11 09:31:54 | <tomsmeding> | and what people use 1-element lists for is cases where you want a list in the first place, i.e. you have a dynamically sized vector (that you don't want to put in an array for some reason) |
| 2025-09-11 09:32:07 | <tomsmeding> | tuples are not dynamically sized so that use case doesn't apply |
| 2025-09-11 09:33:07 | <tomsmeding> | "looks awkward" I can get on board with, but I think tuple sections are also nice, and I don't think the consistency in "(), Solo 1, (1, 2), (1, 2, 3)" is worth enough to not have tuple sections |
| 2025-09-11 09:33:42 | <dminuoso> | tomsmeding: Like I said, I would have preferred (1, _) as tuple section syntax anyway. |
| 2025-09-11 09:33:44 | <dminuoso> | :p |
| 2025-09-11 09:33:44 | <tomsmeding> | Solo not having sufficient instances across the ecosystem is also fair |
| 2025-09-11 09:33:53 | <tomsmeding> | ah I missed that bit |
| 2025-09-11 09:34:11 | <tomsmeding> | Agda does something like that |
| 2025-09-11 09:34:22 | <tomsmeding> | _+ 3 :: Int -> Int |
| 2025-09-11 09:34:35 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 2025-09-11 09:34:57 | <dminuoso> | yeah and more crazily you can declare arbitrary mixfix things with that. |
| 2025-09-11 09:35:01 | <tomsmeding> | yes |
| 2025-09-11 09:35:11 | <dminuoso> | Even if then else is user definable this way, its crazy. |
| 2025-09-11 09:35:12 | <tomsmeding> | if_then_else_ : Bool -> a -> a -> a |
| 2025-09-11 09:35:20 | <dminuoso> | I dont even want to know how that parser is written. |
| 2025-09-11 09:35:40 | ski | would like "composite sections", like `(1 + 2 *)' (being `\x -> 1 + 2 * x') |
| 2025-09-11 09:35:41 | <tomsmeding> | I hear that it's not actually that terrible, but I've never looked at it |
| 2025-09-11 09:36:00 | <tomsmeding> | ski: they already work if the precedence works out; `(1 * 2 +)' does work |
| 2025-09-11 09:36:07 | <tomsmeding> | % :t (1 * 2 +) |
| 2025-09-11 09:36:07 | <yahb2> | (1 * 2 +) :: Num a => a -> a |
| 2025-09-11 09:36:30 | <ski> | yes, but this is specifically for the other way around, with precedence & associativity |
| 2025-09-11 09:36:47 | <tomsmeding> | at that point I'd feel more for dminuoso's syntax |
| 2025-09-11 09:36:49 | <tomsmeding> | (1 + 2 * _) |
| 2025-09-11 09:36:52 | <ski> | @type (?f . ?g .) |
| 2025-09-11 09:36:53 | <lambdabot> | error: |
| 2025-09-11 09:36:53 | <lambdabot> | The operator ‘.’ [infixr 9] of a section |
| 2025-09-11 09:36:53 | <lambdabot> | must have lower precedence than that of the operand, |
| 2025-09-11 09:36:58 | <ski> | this is annoying |
| 2025-09-11 09:37:02 | <tomsmeding> | fair |
| 2025-09-11 09:37:44 | <tomsmeding> | because (.) is defined infixr |
| 2025-09-11 09:38:02 | <tomsmeding> | in general though, GHC doesn't know anything about actual associativity of operators |
| 2025-09-11 09:38:13 | ski | also would not be a fan of `_' for sections |
| 2025-09-11 09:39:21 | <tomsmeding> | dminuoso: have you thought about combining mixfix with precedence and associativity |
| 2025-09-11 09:39:36 | <tomsmeding> | if not, then yes agda does that too |
| 2025-09-11 09:40:26 | <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 09:41:12 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 248 seconds) |
| 2025-09-11 09:41:14 | <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 09:41:20 | <tomsmeding> | er, s/,/+/g |
| 2025-09-11 09:41:27 | <ski> | yes |
| 2025-09-11 09:41:47 | <ski> | i consider tuple sections to be a different animal than operator sections |
| 2025-09-11 09:41:49 | <tomsmeding> | currently there is also an arbitrary line: the partially-applied operator must be at the top level |
| 2025-09-11 09:41:58 | <tomsmeding> | I'm not sure your arbitrary line is better |
| 2025-09-11 09:42:11 | <tomsmeding> | neither is fully general |
| 2025-09-11 09:42:15 | <ski> | mm |
| 2025-09-11 09:42:39 | <tomsmeding> | yours is more general than the current one, granted |
| 2025-09-11 09:42:48 | <ski> | "where \x -> (1,2,x) can be a section" -- not with non-tuple sections |
| 2025-09-11 09:42:50 | × | tromp quits (~textual@2001:1c00:3487:1b00:4ca2:8197:56e4:708) (Ping timeout: 245 seconds) |
| 2025-09-11 09:43:00 | <tomsmeding> | yeah sorry I wrote tuples but I meant + |
| 2025-09-11 09:43:08 | <tomsmeding> | with TupleSections both are already possible |
| 2025-09-11 09:43:15 | <tomsmeding> | and I presume they would remain possible with your proposal |
| 2025-09-11 09:43:18 | <ski> | ah, so `\x -> 1 + 2 + x' ? |
| 2025-09-11 09:43:21 | → | ridcully joins (~ridcully@p57b5234b.dip0.t-ipconnect.de) |
| 2025-09-11 09:43:26 | <tomsmeding> | yes, versus `\x -> 1 + x + 2' |
| 2025-09-11 09:43:50 | <tomsmeding> | and if you say + is commutative, sure, some other non-commutative operator :p |
| 2025-09-11 09:43:50 | <ski> | having non-numeric precedences would also be nice |
| 2025-09-11 09:44:03 | <tomsmeding> | Agda has fractional precedences |
| 2025-09-11 09:44:12 | → | petrichor joins (~jez@user/petrichor) |
| 2025-09-11 09:44:23 | <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 09:44:28 | × | petrichor quits (~jez@user/petrichor) (Remote host closed the connection) |
| 2025-09-11 09:44:43 | <tomsmeding> | that sounds equivalent to numeric precedences, except for less names? |
| 2025-09-11 09:44:58 | <tomsmeding> | an actual serious generalisation would be a precedence lattice |
| 2025-09-11 09:45:14 | <tomsmeding> | but then that feels hard to usably accomplish in practice |
| 2025-09-11 09:45:43 | <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 09:46:49 | × | LainIwakura quits (~LainIwaku@user/LainIwakura) (Quit: Client closed) |
| 2025-09-11 09:46:49 | → | petrichor joins (~jez@user/petrichor) |
| 2025-09-11 09:47:35 | <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 09:48:20 | <ski> | this is a kind of abstract transitivity of precedences & associativity |
| 2025-09-11 09:49:39 | <ski> | having a prefix/suffix version of `(...)' (grouping) would violate this, btw, so that probably still ought to be an exception |
| 2025-09-11 09:50:12 | <ski> | (note that `A o' there is basically a prefix operator, and `q D' a suffix operator) |
| 2025-09-11 09:50:15 | × | petrichor quits (~jez@user/petrichor) (Client Quit) |
All times are in UTC.