Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 95 96 97 98 99 100 101 102 103 104 105 .. 5022
— 502,152 events total
2020-09-20 17:36:07 <c_wraith> but with *just* Num, you've got basically nothing.
2020-09-20 17:36:24 → cosimone joins (~cosimone@2001:b07:ae5:db26:b248:7aff:feea:34b6)
2020-09-20 17:36:25 <hyperisco> I feel like Num without Ord is amiss
2020-09-20 17:36:52 <c_wraith> so... not a fan of complex numbers?
2020-09-20 17:37:23 <hyperisco> you telling me they can't be ordered or are you telling me Ord is too strong
2020-09-20 17:37:39 <merijn> hyperisco: There's two separate and equally valid orderings for them
2020-09-20 17:37:43 <geekosaur> they can't be ordered
2020-09-20 17:37:46 <merijn> Well, technically probably more
2020-09-20 17:37:54 <geekosaur> or, what merijn said.
2020-09-20 17:37:55 <merijn> But they can't be ordered in a arithmetically meaningful way
2020-09-20 17:38:06 <merijn> hyperisco: Consider this
2020-09-20 17:38:22 <merijn> hyperisco: Is "1 + 0i" > than "0 + 1i" or not?
2020-09-20 17:38:29 → Chi1thangoo joins (~Chi1thang@87.112.60.168)
2020-09-20 17:38:55 <geekosaur> basically "Ord" only makes sense if they can be squashed down to a line without data loss. complex numbers, quaternions, etc. have infinitely many such squashings, none of which has any claim to being primary
2020-09-20 17:39:05 <hyperisco> so you're telling me Ord is too strong
2020-09-20 17:39:23 <merijn> You could argue Num should be Eq
2020-09-20 17:39:30 <merijn> Which, in fact, the Haskell Report does
2020-09-20 17:39:37 <merijn> GHC ignores that, however
2020-09-20 17:39:40 → acidjnk_new2 joins (~acidjnk@p200300d0c736584378afc0f7e05aaafd.dip0.t-ipconnect.de)
2020-09-20 17:39:43 <hyperisco> what about the cherished function instance though
2020-09-20 17:39:49 <merijn> The report also mandates a Show instance as superclass of Num
2020-09-20 17:39:58 <merijn> hyperisco: Those aren't legal per the report
2020-09-20 17:40:02 → borne joins (~fritjof@200116b86490460022497ba62715fb72.dip.versatel-1u1.de)
2020-09-20 17:40:08 <merijn> Since they can't have Eq or Show
2020-09-20 17:40:14 <hyperisco> well the report can stuff itself in regards to Num
2020-09-20 17:40:29 <merijn> hyperisco: Well, you wanted Ord
2020-09-20 17:40:29 × wroathe quits (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 260 seconds)
2020-09-20 17:40:34 <merijn> hyperisco: Which requires Eq :p
2020-09-20 17:40:34 <hyperisco> it started this mess
2020-09-20 17:40:45 <merijn> hyperisco: So insisting on Ord for Num kills that instance too :p
2020-09-20 17:41:01 <merijn> It's easy
2020-09-20 17:41:01 <monochrom> "forall n. Num n => n" is very likely the same as "Integer".
2020-09-20 17:41:14 <hyperisco> if you think I'm giving one consistent position here, I'm not
2020-09-20 17:41:15 → wroathe joins (~wroathe@c-73-24-27-54.hsd1.mn.comcast.net)
2020-09-20 17:41:15 × wroathe quits (~wroathe@c-73-24-27-54.hsd1.mn.comcast.net) (Client Quit)
2020-09-20 17:41:20 <merijn> Num is perfectly adequate if you just give up on any notion of "math" definitions of arithmetic
2020-09-20 17:41:33 → wroathe joins (~wroathe@c-73-24-27-54.hsd1.mn.comcast.net)
2020-09-20 17:41:38 <merijn> hyperisco: There've been 50 different Num hierarchies "better" than the current one proposed
2020-09-20 17:41:56 <merijn> But no one uses them, because they're all a pain for anything anyone actually cares about doing
2020-09-20 17:41:57 <phadej> Num is an unsuccessful attempt to unify operations on `Integer` and `Double`
2020-09-20 17:41:58 → shad0w_ joins (~shad0w_@160.202.36.27)
2020-09-20 17:42:06 <monochrom> But you can't squash down those 50 alternatives down to a line. :)
2020-09-20 17:42:15 <hyperisco> I doubt it
2020-09-20 17:42:21 <merijn> Turns out the current Num hierarchy does passably well at "stuff people actually care about"
2020-09-20 17:42:34 <phadej> right now I think that exact and inexact math should just had different operator set :)
2020-09-20 17:42:35 <Cale> I think Num is pretty okay at the moment. The main things which always bothered me before were the Show and Eq constraints, and those are gone.
2020-09-20 17:42:35 <merijn> hyperisco: Well, feel free to work out and propose alternative 51 :)
2020-09-20 17:42:40 <hyperisco> no
2020-09-20 17:42:42 <merijn> Maybe this time someone will get it right :)
2020-09-20 17:43:03 <hyperisco> PureScript has a different hierarchy and soils it with invalid instances
2020-09-20 17:43:15 <Cale> signum/abs being there is a little weird perhaps, but those are always definable in some fashion
2020-09-20 17:43:16 <monochrom> I am somewhat bothered by the opposite, Cale. For example allowing X->Integer to be a Num instance.
2020-09-20 17:43:21 <hyperisco> but other than that, I've personally found ample utility in it
2020-09-20 17:43:43 <merijn> I have no clue about purescript's hierarchy
2020-09-20 17:43:58 <hyperisco> it is more disciplined than a bag called Num
2020-09-20 17:44:06 <phadej> I think PureScript makes the same mistake, by having e.g. Double as part of "the only numeric hierarchy"
2020-09-20 17:44:22 <hyperisco> but then it goes and gives the usual Double instance and pretends Int is Integer
2020-09-20 17:44:43 <monochrom> Then again I'm bothered by signum and abs, too.
2020-09-20 17:44:46 <merijn> hyperisco: Well, what's the alternative?
2020-09-20 17:44:49 → MorrowM joins (~max@bzq-110-168-31-106.red.bezeqint.net)
2020-09-20 17:44:59 <merijn> Do an Ocaml and use a different + for Int and Double?
2020-09-20 17:45:08 <monochrom> Yes.
2020-09-20 17:45:11 <hyperisco> I recommended that
2020-09-20 17:45:24 <merijn> That's one of the worst things in ocaml >.<
2020-09-20 17:45:32 <monochrom> It is why I came over to Haskell. :)
2020-09-20 17:45:32 → Tesseraction joins (~Tesseract@unaffiliated/tesseraction)
2020-09-20 17:45:36 <hyperisco> though the issue starts at division, not +, for Int
2020-09-20 17:45:39 → justanotheruser joins (~justanoth@unaffiliated/justanotheruser)
2020-09-20 17:45:58 <hyperisco> so long as we're willing to accept the reality that Int is a modular ring
2020-09-20 17:46:10 <merijn> hyperisco: Well, how is your hypothetical hierarchy going to unify + for Int and Double and not get this "wrong instance" for Double you're complaining about
2020-09-20 17:46:15 <hyperisco> a hard thing for programmers to do, seems
2020-09-20 17:46:30 <hyperisco> well that's easy
2020-09-20 17:46:37 <hyperisco> you just cast Double out of the hierarchy altogether
2020-09-20 17:46:41 × gestone quits (~gestone@c-98-225-37-68.hsd1.wa.comcast.net) (Quit: Lost terminal)
2020-09-20 17:46:43 <merijn> Right
2020-09-20 17:46:59 <merijn> So then + doesn't work on Double, but you just said the division start at division
2020-09-20 17:47:06 <hyperisco> and then you do the harder thing of figuring out truthful axioms for Double
2020-09-20 17:47:25 <hyperisco> for Int it does
2020-09-20 17:47:48 <hyperisco> for Double the problem started at the beginning
2020-09-20 17:47:55 <dolio> Maybe you could accept that not every type class needs to be a grand mathematical design, and sometimes people just want to overload stuff.
2020-09-20 17:48:23 <hyperisco> frankly that isn't why I use these languages
2020-09-20 17:49:16 <hyperisco> and I find it bemusing how concerned people get about overloading syntax
2020-09-20 17:49:51 <hyperisco> how do we get on if + cannot be used for both Int and Double in the same module
2020-09-20 17:53:17 <maralorn> I wanna design a small library and am uncertain about the design. I want to specify A) a data type representing certain dialog interactions with a user (like a menu, a text input, a yes/no question) and B) multiple implementations of IO actions that execute that dialog. So far so easy. But now I wonder how I can make the type of possible dialogs composable and giving the handlers an option to specify which types of dialogs
2020-09-20 17:53:17 <maralorn> they support. And I wonder if that's worth it. Because for my use case I could probably just have one data type for "dialogs" and extend it whenever I need to.
2020-09-20 17:54:18 <hyperisco> merijn, oh sorry I think the division is fine, though there are different ways to do it, but the problem starts at Euclidean rings because Int is not an integral domain
2020-09-20 17:54:41 <maralorn> On the other hand specifying possible dialog variants in a type level list will probably multiple my development time and lower the ease of use.
2020-09-20 17:55:13 → juuandyy joins (~juuandyy@90.166.144.65)
2020-09-20 17:55:23 × knupfer quits (~Thunderbi@i59F7FF48.versanet.de) (Ping timeout: 240 seconds)
2020-09-20 17:56:08 <hyperisco> merijn, no scratch that, EuclideanRing defines division. :P clumsily remembering the hierarchy
2020-09-20 17:56:14 → perrier-jouet joins (~perrier-j@modemcable012.251-130-66.mc.videotron.ca)
2020-09-20 17:56:25 × orion quits (~orion@unaffiliated/orion) (Ping timeout: 240 seconds)
2020-09-20 17:56:33 ski looks at sshine
2020-09-20 17:56:42 → suppi joins (~suppi@172.246.241.246)
2020-09-20 17:56:51 MarcelineVQ looks at rcloud
2020-09-20 17:56:54 × heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2020-09-20 17:56:54 <hyperisco> there is DivisionRing which defines multiplicative inverses but that can't be closed on Int
2020-09-20 17:57:03 → Lycurgus joins (~niemand@98.4.96.130)
2020-09-20 17:58:13 <hyperisco> but for example, I can count with semirings, and that has been helpful (technically could with a group, but for whatever reason groups are omitted from the hierarchy, painfully)
2020-09-20 17:58:54 → dansho joins (~dansho@ip68-108-167-185.lv.lv.cox.net)
←Prev  Next→
Page 1 .. 95 96 97 98 99 100 101 102 103 104 105 .. 5022

All times are in UTC.