Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 30 31 32 33 34 35 36 37 38 39 40 .. 5022
502,152 events total
2020-09-17 18:22:14 <tomsmeding> except I don't actually use twitter
2020-09-17 18:22:17 <ski> (so, i guess, "seconded")
2020-09-17 18:22:18 <dolio> I've done it.
2020-09-17 18:22:20 <tomsmeding> yes
2020-09-17 18:23:22 × __Joker_ quits (~Joker@180.151.105.86) (Ping timeout: 272 seconds)
2020-09-17 18:23:29 ski . o O ( `Default' )
2020-09-17 18:23:42 Sunblaze21 parts (~sanjay@116.72.71.64) ()
2020-09-17 18:24:33 <frdg> I am trying to install a package with stack: https://dpaste.org/6kxx , how do I know what base versions different ghc's have?
2020-09-17 18:24:47 <monochrom> You can still set the bar lower or higher regarding how much expectation you expect out of your type class.
2020-09-17 18:25:04 bahamas joins (~lucian@unaffiliated/bahamas)
2020-09-17 18:25:35 <monochrom> For example for a field-name type class like HasName, you still have some expectation, even though it's not as high as Ord's.
2020-09-17 18:25:42 acidjnk_new3 joins (~acidjnk@p200300d0c736587164f46f145ae9b6a7.dip0.t-ipconnect.de)
2020-09-17 18:26:12 p-core joins (~Thunderbi@koleje-wifi-0046.koleje.cuni.cz)
2020-09-17 18:27:13 <monochrom> In this case the expectation being "the method X -> String behaves like field projection".
2020-09-17 18:28:08 Sheilong joins (uid293653@gateway/web/irccloud.com/x-wnvbbxjsydmfebcp)
2020-09-17 18:28:09 <monochrom> You can keep it informal like that, or you can go further formalize it.
2020-09-17 18:28:38 <monochrom> You reckon that it doesn't lead to very powerful algorithms.
2020-09-17 18:28:58 irc_user joins (uid423822@gateway/web/irccloud.com/x-rnfyabrjtddmocvm)
2020-09-17 18:29:14 <geekosaur> (…and then you discover lens)
2020-09-17 18:30:07 × tomsmeding quits (~tomsmedin@2a03:b0c0:0:1010::767:3001) (Quit: ZNC 1.7.5 - https://znc.in)
2020-09-17 18:30:08 <monochrom> But lens's potential for powerful algorithms doesn't come from classes like HasName.
2020-09-17 18:30:29 <monochrom> It comes from being able to pass a lens as a parameter.
2020-09-17 18:31:10 gestone joins (~gestone@c-73-97-137-216.hsd1.wa.comcast.net)
2020-09-17 18:31:23 <monochrom> Regarding HasName it's the other way round. The power of lens leads to HasName. HasName leads to not much (apart from what I said), really.
2020-09-17 18:32:31 tomsmeding joins (~tomsmedin@2a03:b0c0:0:1010::767:3001)
2020-09-17 18:33:11 <monochrom> In the case of Default, you have to set the bar pretty low, but it is still not dead zero.
2020-09-17 18:33:42 × v0d1ch quits (~v0d1ch@cable-178-148-120-241.dynamic.sbb.rs) (Ping timeout: 260 seconds)
2020-09-17 18:33:43 <sm[m]> frdg: memorise https://wiki.haskell.org/Base_package#Versions or https://www.fosskers.ca/en/blog/base in your browser
2020-09-17 18:34:01 <monochrom> An expectation is "it's a legal value of your type X, and in a very strong sense: it's also a legal value for all of your functions that take X parameters"
2020-09-17 18:34:12 <dolio> Just having things like `HasName` is very useful.
2020-09-17 18:34:35 <monochrom> In some cases you also get to expect the default value is also the identity element of a suitable monoid.
2020-09-17 18:34:48 __Joker joins (~Joker@180.151.105.86)
2020-09-17 18:35:26 × gestone quits (~gestone@c-73-97-137-216.hsd1.wa.comcast.net) (Ping timeout: 246 seconds)
2020-09-17 18:35:26 <dolio> They're more useful when they're lens type stuff than just `X -> String`, but not necessarily because you can pass them as parameters.
2020-09-17 18:36:15 <dolio> Or, well, they're useful because lenses are more useful than projection functions.
2020-09-17 18:36:36 <dumptruckman> well how about this... can you explain why `data Player = Player { name :: String }` and `data World = World { name :: String }` can't coexist?
2020-09-17 18:36:57 <geekosaur> becuase "name" is defined automatcially as a function
2020-09-17 18:36:58 <monochrom> "name" doubles as a function name.
2020-09-17 18:37:17 <geekosaur> and it can't simultaneously have type Player -> String and World -> String
2020-09-17 18:37:22 <sm[m]> frdg: looks like you should use a newer resolver
2020-09-17 18:37:42 × dbmikus quits (~dbmikus@cpe-76-167-86-219.natsow.res.rr.com) (Remote host closed the connection)
2020-09-17 18:37:50 <dumptruckman> geekosaur: why not? can't the compiler know which is being called?
2020-09-17 18:38:06 <dolio> Not in general.
2020-09-17 18:38:14 × supercoven quits (~Supercove@dsl-hkibng32-54fb54-166.dhcp.inet.fi) (Ping timeout: 256 seconds)
2020-09-17 18:38:18 <geekosaur> there are arguments about type-directed name resolution on the wiki iirc
2020-09-17 18:38:39 <geekosaur> it comes up every time this is discussed
2020-09-17 18:38:43 <frdg> thanks sm[m]
2020-09-17 18:38:44 <monochrom> The compiler knows if you make it a class method.
2020-09-17 18:38:47 <tomsmeding> dumptruckman: automatically deriving Named using Generics; please do not do this! :) https://paste.tomsmeding.com/XkbAiiRJ
2020-09-17 18:38:52 <geekosaur> and the solution is, basically, lens packages which do HasField
2020-09-17 18:38:53 <tomsmeding> wanted to flex my Generics muscles
2020-09-17 18:39:20 <dolio> The problem is that TDNR makes very little sense, because type classes are the sensible type for type-directed name resolution, if you ignore the gatekeeping people have been trying to force on you.
2020-09-17 18:39:39 <geekosaur> (I recommend fclabels or microlens if you do want to play with that; beware of https://ro-che.info/ccc/23)
2020-09-17 18:39:46 × __Joker quits (~Joker@180.151.105.86) (Ping timeout: 260 seconds)
2020-09-17 18:41:10 × stiell quits (~stian@fsf/member/stiell) (Ping timeout: 260 seconds)
2020-09-17 18:41:25 × knupfer quits (~Thunderbi@200116b82cb61c00e890525b81038fc7.dip.versatel-1u1.de) (Ping timeout: 240 seconds)
2020-09-17 18:41:51 <dolio> You don't need any lens packages to just overload 'name' to apply to a bunch of different types.
2020-09-17 18:42:05 coot joins (~coot@37.30.53.120.nat.umts.dynamic.t-mobile.pl)
2020-09-17 18:42:07 <dolio> If that's really what you want to do.
2020-09-17 18:42:35 <dumptruckman> neat
2020-09-17 18:42:43 <dumptruckman> I'll have to read about generics cause that looks crazy
2020-09-17 18:42:51 <tomsmeding> again, this is killing a musquito with a bazooka :)
2020-09-17 18:42:52 exodrifter joins (~exodrifte@cpe-173-172-173-93.tx.res.rr.com)
2020-09-17 18:42:54 <monochrom> I am not against having HasName. I am against having HasName and ending up not actually using it.
2020-09-17 18:42:55 <dumptruckman> particularly all the "junk"
2020-09-17 18:43:25 <monochrom> If you don't have an algorithm of type "HasName t => ... t ..." then you don't need HasName.
2020-09-17 18:44:01 stiell joins (~stian@fsf/member/stiell)
2020-09-17 18:44:03 <dolio> Why? I have overloaded stuff that I don't use generically like that.
2020-09-17 18:44:19 <dolio> Because I want to write `peek ustk` and `peek bstk`.
2020-09-17 18:44:21 <frdg> it is not clear to me what a resolver is, and which different one I should choose with stack.
2020-09-17 18:44:26 <dolio> Where those are different types of stacks.
2020-09-17 18:44:33 <monochrom> OK, well, even when I'm against it, it is not 100% against, there are exceptions.
2020-09-17 18:45:09 <dolio> I mean, by definition, if you have the class, you have at least one thing like that.
2020-09-17 18:45:22 <monochrom> It then comes down to whether overloading the method name improves or impairs clarity.
2020-09-17 18:45:35 × p-core quits (~Thunderbi@koleje-wifi-0046.koleje.cuni.cz) (Ping timeout: 246 seconds)
2020-09-17 18:46:01 <dumptruckman> I guess I look at SNR with this
2020-09-17 18:46:42 <dumptruckman> in Java I would have an interface Person with method getPersonName and World with getWorldName, i'd have Person with getName and World with getName because it is less noise
2020-09-17 18:46:48 <monochrom> No there is no noise here. What you are really looking at is redundancy.
2020-09-17 18:46:58 <dumptruckman> s/would/wouldn't
2020-09-17 18:47:09 <dumptruckman> how is that not noise
2020-09-17 18:47:25 <monochrom> how is that noise instead of redundancy
2020-09-17 18:47:28 <dumptruckman> redundancy that doesn't aid with readability, impo
2020-09-17 18:47:30 <dumptruckman> imo*
2020-09-17 18:47:48 <dumptruckman> it impairs readability by becoming eye strain
2020-09-17 18:48:16 <dumptruckman> also it may lead you to wonder if they represent similar things
2020-09-17 18:48:22 <dumptruckman> or if WorldName is something different than PersonNAme
2020-09-17 18:49:34 <exodrifter> I think "eye strain" is a weak argument? You could install a different color scheme like Solarized. A stronger argument might be "I want to get the name of this entity, and i don't really care what kind of entity it is."
2020-09-17 18:49:42 p-core joins (~Thunderbi@koleje-wifi-0046.koleje.cuni.cz)
2020-09-17 18:49:48 <tomsmeding> what if you define this Named class, giving a 'name' function, but then concede that Generics is too big a gun, and just hand-implement 'name' for each type you want it for
2020-09-17 18:50:06 <tomsmeding> 1. you get your noise-less name function, 2. no weird overengineering
2020-09-17 18:50:08 × DavidEichmann quits (~david@43.240.198.146.dyn.plus.net) (Remote host closed the connection)
2020-09-17 18:50:23 <tomsmeding> downside is a little boilerplate when you define the type, but IMO that's minor
2020-09-17 18:50:38 <exodrifter> you'd have to do that in java anyway if you implemented an interface
2020-09-17 18:50:56 <tomsmeding> indeed :)
2020-09-17 18:51:08 <geekosaur> you still need some boilerplate even with Generics
2020-09-17 18:51:17 <tomsmeding> true, but less
2020-09-17 18:51:59 gestone joins (~gestone@c-73-97-137-216.hsd1.wa.comcast.net)
2020-09-17 18:52:02 × p-core quits (~Thunderbi@koleje-wifi-0046.koleje.cuni.cz) (Client Quit)
2020-09-17 18:52:02 <monochrom> Like I said, I'm not 100% against it, it depends, there are case-by-case ad hoc judgments to be made.
2020-09-17 18:52:21 <monochrom> If you rule that the redundancy helps, keep it. If you rule that the redundancy hurts, remove it.
←Prev  Next→
Page 1 .. 30 31 32 33 34 35 36 37 38 39 40 .. 5022

All times are in UTC.