Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 .. 5022
— 502,152 events total
2020-11-18 19:51:58 <merijn> dolio: You can, but what that does is dumb as hell
2020-11-18 19:52:09 <davean> merijn: So I REALLY don't like our numerical tower.
2020-11-18 19:52:11 <merijn> dolio: That just means you only import those names qualified
2020-11-18 19:52:20 <dolio> Oh, I see what you mean.
2020-11-18 19:52:21 <merijn> davean: I don't like it, but fixing that is less obvious
2020-11-18 19:52:25 × mananamenos_ quits (~mananamen@84.122.202.215.dyn.user.ono.com) (Ping timeout: 264 seconds)
2020-11-18 19:52:28 <merijn> davean: So I'm willing to firgive that
2020-11-18 19:52:34 <monochrom> merijn: Are we listing a few warts of Haskell now?
2020-11-18 19:52:36 → raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2020-11-18 19:53:02 <merijn> dolio: Haskell would be so much better if I could write "import qualified Data.Map as M (Map)" and having "Map" imported unqualified :(
2020-11-18 19:53:11 <davean> merijn: I think theres a few obvious ones. It depends on if you're willing to evolve it (it doesn't seem we are) or insist on jumping to a perfect solution.
2020-11-18 19:53:33 <merijn> davean: I haven't seen any "improvements" that were "strictly better"
2020-11-18 19:53:33 <monochrom> I just have one to gripe about, all the others I really don't mind. This one: The tendency of the community to pretend that it is a dependently typed language.
2020-11-18 19:53:36 <dolio> I think most of the 'perfect solutions' are probably actually not that good.
2020-11-18 19:53:43 <merijn> monochrom: Oh, definitely
2020-11-18 19:53:47 <merijn> dolio++
2020-11-18 19:54:04 <davean> merijn: well making it so most Num instances don't have undefineds ...
2020-11-18 19:54:05 <dminuoso> merijn: Mmm, I dont like that either.
2020-11-18 19:54:18 <dolio> They generally assume that borrowing dozens of mathematical classificationsn is good.
2020-11-18 19:54:19 <monochrom> Ah yeah that would be a nice feature merijn.
2020-11-18 19:54:19 <merijn> I don't want "mathematically accurate" I want "useful for practical things in the real world" :p
2020-11-18 19:54:26 <dminuoso> Ah, perhaps I can just stick it in a newtype, that would only require RankNTypes on the definition site
2020-11-18 19:54:55 <merijn> Who gives a fuck that double operations aren't associative? Just let me safely turn Int64 into Int32 in a remotely safe and sane way...
2020-11-18 19:55:30 <monochrom> But I think I have a better syntax. Here is the full form, and you can omit various parts: import Data.Map (Map, (!)) qualified as M (null, insert)
2020-11-18 19:55:49 <merijn> monochrom: That would require a change to the parser, etc.
2020-11-18 19:55:58 <monochrom> likewise for hiding, e.g., import Data.Map hiding (null) qualified as M hiding (insert)
2020-11-18 19:56:19 <monochrom> Yeah I know, but it is both more complete and less ambiguous
2020-11-18 19:56:20 <merijn> Qualified re-exports would be a killer feature too, tbh
2020-11-18 19:56:34 <monochrom> I mean s/less ambiguous/more guessable/
2020-11-18 19:56:36 <geekosaur> but it's not an incompatible change
2020-11-18 19:56:40 → falafel joins (~falafel@2601:547:1303:b30:7811:313f:d0f3:f9f4)
2020-11-18 19:56:52 <geekosaur> I think qualified re-exports require help from the linker though
2020-11-18 19:56:54 <merijn> geekosaur: Which one?
2020-11-18 19:57:20 <geekosaur> monochrom's suggested import syntax
2020-11-18 19:57:31 <merijn> monochrom: Actually, I have a major objection to your proposed syntax
2020-11-18 19:58:11 × mananamenos quits (~mananamen@84.122.202.215.dyn.user.ono.com) (Ping timeout: 260 seconds)
2020-11-18 19:58:46 <merijn> monochrom: You violated the key principle (that IMO should be a core value in syntax design) of "accommodate a non-awkward way of linewrapping this when import lists get long..."
2020-11-18 19:58:49 → mananamenos joins (~mananamen@84.122.202.215.dyn.user.ono.com)
2020-11-18 19:58:59 <dolio> Didn't one of the recent versions add an option for 'qualified' later in the import?
2020-11-18 19:59:05 <merijn> Haskell's current syntax fails that horribly too
2020-11-18 19:59:27 <merijn> dolio: All that does is let you write "import Data.Map qualified" instead of "import qualified Data.Map"
2020-11-18 19:59:33 × nbloomf quits (~nbloomf@2600:1700:ad14:3020:1c60:9ba4:8bf9:ee34) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2020-11-18 19:59:34 <dolio> Right, okay.
2020-11-18 19:59:35 <davean> merijn: Don't like int-cast?
2020-11-18 19:59:36 <merijn> gratuitously breaking all haskell source/parse thigns
2020-11-18 20:00:14 <monochrom> I think my proposal respects that principle.
2020-11-18 20:00:15 <merijn> davean: The fact that it's not built into Num is gross negligence
2020-11-18 20:00:39 <merijn> monochrom: How do you line wrap when the import list becomes, like, 10 entries long?
2020-11-18 20:00:55 <davean> merijn: but we don't have to build it into Num, and I don't think it makes sense to. A lot don't have sensible conversions?
2020-11-18 20:01:11 <merijn> davean: Also, no, int-cast's intCastMaybe isn't good enough
2020-11-18 20:01:47 <merijn> Ideally you have "intCastDynamic :: (Integral a, Integral b) => a -> Either (a, b) b"
2020-11-18 20:01:58 <merijn> i.e. don't just fail, give me the max possible value + remainder
2020-11-18 20:02:14 <merijn> That's much more useful
2020-11-18 20:02:28 × mastarija quits (~mastarija@93-136-96-155.adsl.net.t-com.hr) (Ping timeout: 265 seconds)
2020-11-18 20:02:39 <monochrom> https://paste.tomsmeding.com/Fxc7LZRQ
2020-11-18 20:02:51 <merijn> davean: We have fromIntegral in Num
2020-11-18 20:02:54 <davean> monochrom: its built in to https://hackage.haskell.org/package/base-4.13.0.0/docs/Data-Bits.html Because thats where it makes some sense.
2020-11-18 20:03:15 <merijn> eh, fromInteger, I mean
2020-11-18 20:03:32 <merijn> Why is having only an unsafe fromInteger better/more sensible then a checking variant?
2020-11-18 20:03:55 <merijn> monochrom: Yeah, that's a super ugly and awkward way to line wrap :p
2020-11-18 20:04:24 <monochrom> OK, what is a nicer way to line-wrap?
2020-11-18 20:04:29 <davean> merijn: why is "negate" there too? Because Num is broken.
2020-11-18 20:04:33 <merijn> I haven't thought of one yet
2020-11-18 20:04:52 <merijn> davean: Didn't you *just* say that "it's broken" wasn't a reason to not improve things? :p
2020-11-18 20:05:18 <monochrom> What is super ugly and awkward about it?
2020-11-18 20:05:23 <davean> merijn: yes, but you asked why "fromInteger" is there, I think "Num wasn't thought out, and is fundimentally broken" is the reason.
2020-11-18 20:05:42 <merijn> davean: "to convert numerical literals" is why
2020-11-18 20:05:55 <merijn> But converting numerical literals in a silently corrupting way is bad
2020-11-18 20:05:57 <juri_> davean: try looking at Rational sometime.
2020-11-18 20:05:57 → nbloomf joins (~nbloomf@2600:1700:ad14:3020:d091:432d:3cee:b0b2)
2020-11-18 20:06:02 <davean> juri_: Trust me I have
2020-11-18 20:06:13 <merijn> Actually, what we *really* need is https://hackage.haskell.org/package/validated-literals built into base
2020-11-18 20:06:15 <davean> MOST of my problems programming Haskell these days come from our Numeric classes being wrong.
2020-11-18 20:06:23 <merijn> or rather, GHC
2020-11-18 20:06:27 <davean> You simply can't be generic in your number type with Haskell's tower.
2020-11-18 20:06:30 → unfixpoint joins (1f0a965a@31-10-150-90.cgn.dynamic.upc.ch)
2020-11-18 20:06:33 <davean> Because all the classes are just lies.
2020-11-18 20:06:34 × mirrorb2rd quits (~psutcliff@89.40.182.152) (Quit: Leaving)
2020-11-18 20:07:27 <unfixpoint> I'm having problems with some data type that uses RankNTypes.. I'm trying to abstract the way I connect to a database with holding `(Connection -> IO a) -> IO a` in a reader thing.
2020-11-18 20:07:39 <unfixpoint> I condensed the problem to this: https://pastebin.com/raw/geEHaeFk
2020-11-18 20:08:05 <merijn> unfixpoint: That's not a RankNType, that's an existential
2020-11-18 20:08:13 × SanchayanMaity quits (~Sanchayan@106.201.35.233) (Quit: SanchayanMaity)
2020-11-18 20:08:18 <merijn> Which means the forall is in the wrong place
2020-11-18 20:08:32 × heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2020-11-18 20:08:36 <merijn> Because it's current location already has an implicit one in haskell
2020-11-18 20:08:46 <monochrom> I'm pretty sure all you need is exposing the "a" as a type parameter.
2020-11-18 20:08:47 <unfixpoint> Though the errors slightly changed, now it says '(Connection -> IO a1) -> IO a1' cannot be matched with '(forall a. (Connection -> IO a) -> IO a)' but in the actual problem it is 'a' cannot matched 'a0'
2020-11-18 20:09:08 <monochrom> data R a = R ((Connection -> IO a) -> IO a)
2020-11-18 20:09:15 → hidedagger joins (~nate@unaffiliated/hidedagger)
2020-11-18 20:09:45 <koz_> Am I the only person who mis-spells Data.Vector's (!?) as (?!) all the time?
2020-11-18 20:10:12 <monochrom> Heh. Yesterday I kept misspelling "dictionary" as "directory".
2020-11-18 20:10:28 × dxld quits (~dxld@rush.pub.dxld.at) (Quit: Bye)
2020-11-18 20:10:30 <koz_> monochrom: Lol... some similarities there for sure.
2020-11-18 20:10:50 <merijn> unfixpoint: Anyway, RankN isn't what you want here, you either want existential quantification or just a parametric 'R' as monochrom suggests
2020-11-18 20:10:52 <unfixpoint> monochrom: Not sure if it will work?
2020-11-18 20:11:29 <unfixpoint> But when I write it GHC yelled at me I should be using RankN. Is Existential implied by RankN
2020-11-18 20:11:31 <unfixpoint> ?
2020-11-18 20:11:59 <merijn> No, they're different things
2020-11-18 20:12:06 → gumbish joins (4913050a@c-73-19-5-10.hsd1.wa.comcast.net)
2020-11-18 20:12:25 <merijn> unfixpoint: "GHC tells you to enable extension X" is only loosely correlated with "actually needing/wanting X"
←Prev  Next→
Page 1 .. 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 .. 5022

All times are in UTC.