Logs: freenode/#haskell
| 2020-10-05 16:05:16 | × | GyroW quits (~GyroW@ptr-48ujrfd1ztq5fjywfw3.18120a2.ip6.access.telenet.be) (Changing host) |
| 2020-10-05 16:05:16 | → | GyroW joins (~GyroW@unaffiliated/gyrow) |
| 2020-10-05 16:05:24 | <lortabac> | dsal: if you know you are working with lists, why making your signature more ambiguous? |
| 2020-10-05 16:05:35 | <fog23> | and then you show them cojoin for a graph |
| 2020-10-05 16:05:40 | <fog23> | pointer... |
| 2020-10-05 16:05:40 | <monochrom> | Well yeah, it's a long time ago, also I was not (and am not) very strongly convicted about it. |
| 2020-10-05 16:06:07 | <c_wraith> | lortabac: If you're writing code that works correctly with more types than list, why not make it more polymorphic so that callers know the implementation space is more restricted? |
| 2020-10-05 16:06:09 | <monochrom> | It is also true of Num, too. |
| 2020-10-05 16:06:22 | <Cheery> | adding dependency "pandoc" and almost bursting in laughter |
| 2020-10-05 16:06:24 | <fog23> | you get traverse_i, where `i' is a "structure directing index, which is a navigation to the pointer to take it to the "next" position |
| 2020-10-05 16:06:37 | <fog23> | so that a carried copy of the future reference can be placed at the bridge locations |
| 2020-10-05 16:06:39 | <lortabac> | c_wraith: I don't understand |
| 2020-10-05 16:06:45 | <monochrom> | Sometimes I first tell the white lie "(+) :: Integer -> Integer -> Integer" and then later when the students are ready I'll explain type classes. |
| 2020-10-05 16:07:33 | <dsal> | monochrom: I think that makes sense for the Foldable example as well. Things other than lists have length, but you can talk about just lists at first. |
| 2020-10-05 16:08:10 | <fog23> | and then you explain about matricies and functions not supporting quotients - so that we need rings not groups for the extension to monoid most general to represent "polynomial functions" |
| 2020-10-05 16:08:20 | <Cheery> | I'm also going to tell myself a white lie. I'm going to say that something like RelaxNG but on type level can be useful even if I didn't do it properly, and only to writeout stuff reliably. |
| 2020-10-05 16:08:34 | <monochrom> | But here is a downside I don't know how to solve. |
| 2020-10-05 16:08:53 | <monochrom> | Despite my white lies, error messages are going to leak the cold hard truth. |
| 2020-10-05 16:09:14 | <c_wraith> | lortabac: the more polymorphic a type is, the fewer possible implementations it has. Making something more polymorphic often (not always) makes it clearer what it does, because the type eliminates more possible things that it could be doing. |
| 2020-10-05 16:09:21 | <monochrom> | And 90% of the time it happens when one is not ready to explain or learn what the error message is saying. |
| 2020-10-05 16:09:31 | <fog23> | yeah, how could you ensure that if you made a functional version of call by variable, that it wouldnt break purity |
| 2020-10-05 16:09:50 | <fog23> | or is there a weaker version of purity where you could still make some guaranties |
| 2020-10-05 16:09:55 | <lortabac> | c_wraith: fair point, but in my experience this is more often the case with parametric polymorphism than with ad-hoc polymorphism |
| 2020-10-05 16:09:56 | <monochrom> | So this perpetuates people's bad habit of ignoring error messages. |
| 2020-10-05 16:10:11 | <dolio> | I pretty much always use fmap for mapping over lists, and I have essentially 0 problems. |
| 2020-10-05 16:10:14 | <Cheery> | monochrom: does your students have haskell-language-server on vscode? |
| 2020-10-05 16:10:29 | <Chousuke> | monochrom: sounds like you need some kind of learn_prelude that swaps out the generic stuff with your dirty lies :) |
| 2020-10-05 16:10:29 | <monochrom> | (Well, people see there is an error. People just disbelieve that the message content is informative.) |
| 2020-10-05 16:10:32 | <fog23> | i cant believe that C# has "inheretence" to mean extensible records |
| 2020-10-05 16:11:06 | → | mav1 joins (~mav@i59F4E23A.versanet.de) |
| 2020-10-05 16:11:15 | <fog23> | dolio: 0 problems is a side effect of not enough fun |
| 2020-10-05 16:11:34 | → | LKoen joins (~LKoen@81.255.219.130) |
| 2020-10-05 16:12:02 | → | mananamenos joins (~mananamen@84.122.202.215.dyn.user.ono.com) |
| 2020-10-05 16:12:09 | × | conal quits (~conal@64.71.133.70) (Ping timeout: 256 seconds) |
| 2020-10-05 16:12:33 | <fog23> | and then you combine erlang with go and haskell and get pure structure-concurrent graphical functional languages |
| 2020-10-05 16:12:42 | × | jgt1 quits (~jgt@78.26.168.236) (Ping timeout: 272 seconds) |
| 2020-10-05 16:12:44 | <c_wraith> | monochrom: how terrible is the user experience of giving them an alternate Prelude to work with? |
| 2020-10-05 16:12:54 | <monochrom> | I haven't tried. |
| 2020-10-05 16:13:25 | × | wroathe quits (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 240 seconds) |
| 2020-10-05 16:13:30 | <fog23> | c_wraith: about as terrible as most of the forms of pety-facism |
| 2020-10-05 16:13:50 | <fog23> | ie, context dependent! |
| 2020-10-05 16:14:00 | → | albert_99 joins (~Albert@p200300e5ff0b5b425d211d042df94ce7.dip0.t-ipconnect.de) |
| 2020-10-05 16:14:01 | × | da39a3ee5e6b4b0d quits (~textual@n11211935170.netvigator.com) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2020-10-05 16:14:05 | <lortabac> | dolio: it's not about problems, but more about better error messages and for example better inference when using typed holes to get the type of an intermediate expression |
| 2020-10-05 16:15:15 | <lortabac> | replacing fmap with map has helped me more than once when I was stuck in dealing with complex data structures |
| 2020-10-05 16:15:26 | <fog23> | yeah, its not a bad idea to make a synonym using TypeApplications for your common types |
| 2020-10-05 16:15:26 | <lortabac> | of course YMMV |
| 2020-10-05 16:15:33 | <fog23> | such as the "has" function |
| 2020-10-05 16:15:33 | <monochrom> | Actually, empirically, I have been doing nothing to the dilemma, and the students survived just fine. :) |
| 2020-10-05 16:15:52 | → | conal joins (~conal@172.255.125.158) |
| 2020-10-05 16:16:27 | <fog23> | otherwise the type applications are optional, and you end up with (fmap . fmap . fmap) and its sometimes impossible to read which types they apply to |
| 2020-10-05 16:16:54 | <dsal> | lortabac: But you're solving the problem for exactly one function on exactly one type. The problem exists both in other functions and other types. |
| 2020-10-05 16:16:54 | <fog23> | explicit type applications would solve that, but they are optional, so the better practive is that of map |
| 2020-10-05 16:17:31 | <fog23> | just make the synonym when you make the instance as a good style |
| 2020-10-05 16:17:33 | <monochrom> | But as usual, whereas a more general type restricts implementation space, it relaxes usage space, and some usages are potential mistakes (the same reason we have occurs check and ban infinite types). |
| 2020-10-05 16:17:41 | <monochrom> | @quote monochrom dialectic |
| 2020-10-05 16:17:41 | <lambdabot> | monochrom says: Programming is a dialectic class struggle between the author and the user. My freedom is your slavery. Your ignorance is my strength. |
| 2020-10-05 16:17:55 | × | urdh quits (~urdh@unaffiliated/urdh) (Ping timeout: 240 seconds) |
| 2020-10-05 16:18:05 | → | wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2020-10-05 16:18:24 | <fog23> | or, equivalently good practice, use type applications as a form of code commenting |
| 2020-10-05 16:18:37 | <fog23> | with the lesser number of synonyms |
| 2020-10-05 16:18:39 | <dsal> | lambdabot: that monochrom dude is clever |
| 2020-10-05 16:18:47 | → | knupfer1 joins (~Thunderbi@200116b82cef8300c13273ee6919ca7e.dip.versatel-1u1.de) |
| 2020-10-05 16:18:47 | × | knupfer1 quits (~Thunderbi@200116b82cef8300c13273ee6919ca7e.dip.versatel-1u1.de) (Client Quit) |
| 2020-10-05 16:18:53 | <fog23> | aka, map depreciated following since @ |
| 2020-10-05 16:18:54 | <monochrom> | :) |
| 2020-10-05 16:18:58 | × | knupfer quits (~Thunderbi@87.123.206.236) (Quit: knupfer) |
| 2020-10-05 16:19:36 | <fog23> | that Hegelian synergy |
| 2020-10-05 16:19:38 | → | knupfer joins (~Thunderbi@200116b82cef830020ab55033e39ebbd.dip.versatel-1u1.de) |
| 2020-10-05 16:19:42 | <dsal> | I'm not good at type applications, but that seems like a good way to get you there. |
| 2020-10-05 16:19:53 | × | Falkeo quits (5631fd8b@ip-86-49-253-139.net.upcbroadband.cz) (Remote host closed the connection) |
| 2020-10-05 16:20:00 | → | urdh joins (~urdh@unaffiliated/urdh) |
| 2020-10-05 16:20:07 | <fog23> | ah, yeah, then you get plenty of foralls |
| 2020-10-05 16:20:13 | <dsal> | :t fmap @([Int] -> [Int]) |
| 2020-10-05 16:20:15 | <lambdabot> | error: |
| 2020-10-05 16:20:15 | <lambdabot> | Pattern syntax in expression context: fmap@(_) |
| 2020-10-05 16:20:15 | <lambdabot> | Did you mean to enable TypeApplications? |
| 2020-10-05 16:20:29 | <fog23> | % :t fmap @([Int] -> [Int]) |
| 2020-10-05 16:20:30 | <yahb> | fog23: ; <interactive>:1:8: error:; * Expected kind `* -> *', but `[Int] -> [Int]' has kind `*'; * In the type `([Int] -> [Int])'; In the expression: fmap @([Int] -> [Int]) |
| 2020-10-05 16:20:48 | <fog23> | % :t fmap @[] @Int |
| 2020-10-05 16:20:48 | <yahb> | fog23: (Int -> b) -> [Int] -> [b] |
| 2020-10-05 16:20:59 | <fog23> | % :t fmap @[] @Int @Int |
| 2020-10-05 16:21:00 | <yahb> | fog23: (Int -> Int) -> [Int] -> [Int] |
| 2020-10-05 16:21:05 | <fog23> | there you go |
| 2020-10-05 16:21:07 | × | topos quits (~topos@138.197.1.46) (Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in) |
| 2020-10-05 16:21:17 | <fog23> | so map = fmap @[] |
| 2020-10-05 16:21:28 | → | topos joins (uid467876@gateway/web/irccloud.com/x-twpqbqvekrcsozee) |
| 2020-10-05 16:21:38 | <fog23> | i dont think the @a @b are required to see what the fmap is acting on |
| 2020-10-05 16:22:07 | → | Stanley00 joins (~stanley00@unaffiliated/stanley00) |
| 2020-10-05 16:22:17 | <dsal> | More importantly, you fix your error messages by, instead of replacing each function name to match what you think you're working with, just annotating it with what you think you're working with. |
| 2020-10-05 16:22:24 | × | mpereira quits (~mpereira@2a02:810d:f40:d96:1c35:7f2e:59ff:953) (Remote host closed the connection) |
| 2020-10-05 16:22:42 | × | wroathe quits (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 256 seconds) |
| 2020-10-05 16:23:10 | <dsal> | % :t fmap @[] |
| 2020-10-05 16:23:10 | <yahb> | dsal: (a -> b) -> [a] -> [b] |
| 2020-10-05 16:23:22 | <fog23> | i guess its either, make synonyms everytime you write an instance. or, write type applications everywhere. or (the seemingly better way) make *some* synonyms, for the more common things, and use TypeApplications where otherwise your (fmap . fmap . fmap) would be unintelligable |
| 2020-10-05 16:23:28 | <dsal> | % :t fmap succ |
| 2020-10-05 16:23:28 | <yahb> | dsal: (Functor f, Enum b) => f b -> f b |
| 2020-10-05 16:23:30 | <dsal> | % :t fmap @[] succ |
| 2020-10-05 16:23:30 | → | wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2020-10-05 16:23:30 | <yahb> | dsal: Enum b => [b] -> [b] |
All times are in UTC.