Logs: freenode/#haskell
| 2020-11-18 20:12:31 | <monochrom> | That's an XY problem. |
| 2020-11-18 20:12:48 | <merijn> | unfixpoint: GHC guess you need RankN from what you *wrote*, not from what you *want* |
| 2020-11-18 20:13:00 | <monochrom> | Are you an expert? Because GHC suggestions assume you're an expert and you merely made a typo. |
| 2020-11-18 20:13:11 | → | dxld joins (~dxld@80-109-136-248.cable.dynamic.surfer.at) |
| 2020-11-18 20:13:25 | <gumbish> | XY problem? |
| 2020-11-18 20:13:29 | → | Boomerang joins (~Boomerang@xd520f68c.cust.hiper.dk) |
| 2020-11-18 20:13:37 | <tomjaguarpaw> | I think that's a YX problem. |
| 2020-11-18 20:13:39 | → | rekahsoft joins (~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com) |
| 2020-11-18 20:13:42 | <monochrom> | It never realizes that 99% of these errors are because you made a wrong design and you tried an overkill. |
| 2020-11-18 20:13:45 | <merijn> | gumbish: https://xyproblem.info/ |
| 2020-11-18 20:13:48 | <unfixpoint> | monochrom: I'm not trying to argue this, not an expert |
| 2020-11-18 20:14:15 | <unfixpoint> | tomjaguarpaw: What do I actually want to do? |
| 2020-11-18 20:14:17 | <geekosaur> | ghc has to guess what you intended from what you wrote. In this case its guess was wrong |
| 2020-11-18 20:14:22 | × | AlterEgo- quits (~ladew@124-198-158-163.dynamic.caiway.nl) (Quit: Leaving) |
| 2020-11-18 20:15:37 | <merijn> | unfixpoint: That depends what your intention for 'R' is |
| 2020-11-18 20:15:38 | <geekosaur> | It doesn't try very hard because it can't really know what you intended, it just went by what would make what you wrote syntactically correct. But only syntactically, not semantically |
| 2020-11-18 20:16:54 | <unfixpoint> | The 'R' basically holds information how to connect among other things (ie. has other fields as well) |
| 2020-11-18 20:17:31 | <merijn> | unfixpoint: Right, but why does the 'a' have to be hidden? Why does monochrom's suggestion of just writing 'R a' not work? |
| 2020-11-18 20:17:43 | <unfixpoint> | I could in theory have a `data R = R { connectInfo :: (Host,Port,Creds) , ... }` actually |
| 2020-11-18 20:18:01 | × | hidedagger quits (~nate@unaffiliated/hidedagger) (Quit: WeeChat 2.9) |
| 2020-11-18 20:18:31 | hackage | haveibeenpwned 0.2.0.0 - Library for checking for weak/compromised passwords. https://hackage.haskell.org/package/haveibeenpwned-0.2.0.0 (abrar) |
| 2020-11-18 20:18:50 | → | AlterEgo- joins (~ladew@124-198-158-163.dynamic.caiway.nl) |
| 2020-11-18 20:18:54 | <unfixpoint> | It was a question, I'm not sure whether it will work. |
| 2020-11-18 20:19:33 | × | idhugo quits (~idhugo@80-62-116-101-mobile.dk.customer.tdc.net) (Ping timeout: 260 seconds) |
| 2020-11-18 20:19:36 | <merijn> | unfixpoint: You can certainly do *that*, because I have, but that sounds more like something where you'll want existentials, depending on the exact design |
| 2020-11-18 20:19:50 | → | hidedagger joins (~nate@unaffiliated/hidedagger) |
| 2020-11-18 20:20:22 | <unfixpoint> | geekosaur: I'm sure someone meant well with those error messages (probably a lot of work), but maybe it should only try what is possible or make sure that the error is actually what it says. |
| 2020-11-18 20:20:28 | × | hidedagger quits (~nate@unaffiliated/hidedagger) (Client Quit) |
| 2020-11-18 20:20:44 | <merijn> | the error is what it is, the suggested fix isn't always |
| 2020-11-18 20:20:50 | <unfixpoint> | merijn: I see, I'll try where I get from here. |
| 2020-11-18 20:21:07 | <monochrom> | This is why IMO such "helpful" hints are evil. |
| 2020-11-18 20:21:11 | <merijn> | unfixpoint: I like to call that "OO" Haskell |
| 2020-11-18 20:21:26 | <monochrom> | And I say that the poeple who promoted those hints are do-gooders. |
| 2020-11-18 20:21:30 | hackage | haveibeenpwned 0.2.0.1 - Library for checking for weak/compromised passwords. https://hackage.haskell.org/package/haveibeenpwned-0.2.0.1 (abrar) |
| 2020-11-18 20:21:31 | <unfixpoint> | Wait, why OO-Haskell? |
| 2020-11-18 20:21:33 | <merijn> | unfixpoint: persistent uses it, so maybe you wanna have a alook at what they do |
| 2020-11-18 20:22:08 | <merijn> | unfixpoint: Because having a datatype that exposes abstract API that you can use without knowing its internals is basically just OO interfaces? :) |
| 2020-11-18 20:22:32 | <dminuoso> | Unsure what that has to do with "object oriented" though |
| 2020-11-18 20:22:40 | <dminuoso> | That's just encapsulation. :) |
| 2020-11-18 20:22:44 | → | Deide joins (~Deide@217.155.19.23) |
| 2020-11-18 20:22:46 | <unfixpoint> | I guess that's true, yeah. I always considered typeclasses as that |
| 2020-11-18 20:23:00 | × | rekahsoft quits (~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com) (Remote host closed the connection) |
| 2020-11-18 20:23:30 | <merijn> | unfixpoint: I find typeclass rather "entirely unlike OO" the more you consider them :) |
| 2020-11-18 20:23:43 | <merijn> | unfixpoint: You might wanna look at this and the code that uses it to get inspiration? https://github.com/yesodweb/persistent/blob/a819276a883b89ac898bf61ff7a1cc8a8bf3cd50/persistent/Database/Persist/Sql/Types/Internal.hs#L79-L181 |
| 2020-11-18 20:23:59 | <unfixpoint> | The interface part though. |
| 2020-11-18 20:24:06 | <dminuoso> | merijn: Arguably, the core theme that makes OO OO, is one of two things. It's either smalltalk-esque message passing, or its subtyping. Or a combination of both. The "methods" and "internals/externals" is just language ergonomics that has nothing to do with object orientation. |
| 2020-11-18 20:24:23 | → | boxscape joins (54a35f37@gateway/web/cgi-irc/kiwiirc.com/ip.84.163.95.55) |
| 2020-11-18 20:24:24 | <unfixpoint> | merijn: ty! |
| 2020-11-18 20:24:36 | <merijn> | unfixpoint: And how it gets used: https://github.com/yesodweb/persistent/blob/master/persistent-sqlite/Database/Persist/Sqlite.hs#L222-L278 |
| 2020-11-18 20:24:44 | → | rekahsoft joins (~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com) |
| 2020-11-18 20:25:00 | <dminuoso> | That is, whether you write `f->g()`, `f.g()`, `f(g)`, `g f` these are just visual considerations, trying to nudge your thinking into one direction |
| 2020-11-18 20:25:10 | <boxscape> | it's weird, sometimes programming with type families actually feels more convenient than with regular functions, because they already support visible dependent as well as relevant quantification without Singletons |
| 2020-11-18 20:25:50 | <boxscape> | Though I imagine I'll lose that feeling once I actually start writing term-level functions that use these type families .... |
| 2020-11-18 20:25:50 | → | cosimone joins (~cosimone@2001:b07:ae5:db26:d849:743b:370b:b3cd) |
| 2020-11-18 20:27:16 | × | knupfer quits (~Thunderbi@i5E86B4DB.versanet.de) (Ping timeout: 240 seconds) |
| 2020-11-18 20:28:09 | <unfixpoint> | Not sure if he's right (he was kind of arrogant) but my prof claimed the invention of *information hiding* and his language (Eiffel) sure was/is OO |
| 2020-11-18 20:28:41 | <unfixpoint> | Then again just because an XY-language introduces a feature doesn't mean it's inherent to XY-languages |
| 2020-11-18 20:28:47 | <boxscape> | OO means many different things to different people, especially the person who came up with the term |
| 2020-11-18 20:28:49 | <ski> | abstract data types is also about "information hiding" (and is different from OO) |
| 2020-11-18 20:29:11 | <dminuoso> | unfixpoint: information hiding can appear at many different levels. it can happen across systems, architecturally, across libraries, modules |
| 2020-11-18 20:30:07 | × | luto1 quits (~luto@84.39.117.57) (Ping timeout: 256 seconds) |
| 2020-11-18 20:30:17 | <ski> | with parametric polymorphism and type classes, you can say `maximum :: Ord a => [a] -> a'. you can't really say that, with OO |
| 2020-11-18 20:30:37 | <dminuoso> | Well.. you can.. |
| 2020-11-18 20:31:00 | <dminuoso> | elixir protocols explore that mixture |
| 2020-11-18 20:31:30 | <ski> | with bounded polymorphism, you can say something akin to that. but that's assuming you also have (bounded) parametric polymorphism |
| 2020-11-18 20:31:39 | <unfixpoint> | interface Ordering<X> { maximum :: List<X> -> X } or something. I haven't OO'ed for a while |
| 2020-11-18 20:31:45 | × | AlterEgo- quits (~ladew@124-198-158-163.dynamic.caiway.nl) (Quit: Leaving) |
| 2020-11-18 20:31:57 | <ski> | right, the `<X>' there implies parametric polymorphism |
| 2020-11-18 20:32:28 | <unfixpoint> | Lol true, so which OO-language doesn't have parametric polymorphism then? |
| 2020-11-18 20:32:40 | <dminuoso> | C++ for starters |
| 2020-11-18 20:32:43 | <merijn> | unfixpoint: Some do (in some forms) |
| 2020-11-18 20:32:56 | <monochrom> | The <X> was definitely alien to OO. |
| 2020-11-18 20:32:58 | <merijn> | unfixpoint: Java/C# generics are (basically) parametric polymorphism |
| 2020-11-18 20:32:59 | <dminuoso> | The existence of template specializations puts a nail into that coffin. |
| 2020-11-18 20:33:28 | <merijn> | oh, wait, the question was "which doesn't" |
| 2020-11-18 20:33:36 | <merijn> | Python :p |
| 2020-11-18 20:33:50 | <dolio> | Java didn't have it until version 5. |
| 2020-11-18 20:34:19 | <monochrom> | Java learned <X> from Wadler's Pizza. Not even from C++. |
| 2020-11-18 20:34:20 | <boxscape> | seems kind of weird to even ask the question of whether a language without static typing has parametric polymorphism |
| 2020-11-18 20:34:35 | <ski> | OO bundles methods with an object. type classes doesn't do that |
| 2020-11-18 20:34:38 | <boxscape> | It's quite possible that the correct answer is "no" but it almost feels to me like it should be "undefined" |
| 2020-11-18 20:34:39 | <monochrom> | perhaps apart from borrowing the notation |
| 2020-11-18 20:35:30 | <monochrom> | A dynamically typed language has maximum polymorphism and non-existent parametric. |
| 2020-11-18 20:35:42 | <boxscape> | I see |
| 2020-11-18 20:36:00 | <monochrom> | (To remind you that there are many different, conflicting polymorphisms, too.) |
| 2020-11-18 20:36:09 | <dminuoso> | unfixpoint: Also recall, there's two different notions of "object-oriented". One is the heritage ranging all the way back to smalltalk, and the other with simula (they both have possibly more ancient ancestors) |
| 2020-11-18 20:36:28 | <ski> | @where on-understanding |
| 2020-11-18 20:36:28 | <lambdabot> | "On Understanding Types, Data Abstraction, and Polymorphism" by Luca Cardelli,Peter Wegner in 1985-12 at <http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf> |
| 2020-11-18 20:37:16 | <dminuoso> | Often nowadays people understand it as the second, as class with inheritance and everything that belongs to it, though the original idea largely influenced by Alan Kay and others is more about message passing. |
| 2020-11-18 20:38:11 | <dminuoso> | Very broadly where program parts are conceptual objects with internal state, exchanging messages and thus interacting with each other |
| 2020-11-18 20:38:32 | <dminuoso> | A style certainly not respected by Java enthusiasts as much |
| 2020-11-18 20:38:34 | <boxscape> | https://i.imgur.com/iag7eoN.png |
| 2020-11-18 20:38:36 | <unfixpoint> | I understand it as the latter then, message passing is separate to me. But I'm young it seems (certainly did I never program in Java 5) |
| 2020-11-18 20:40:29 | <ski> | given `interface Counter { int tick(); void reset(); }' in Java, the object type `Counter' corresponds in Haskell to `exists a. Counter a *> a', assuming `class Counter a where tick :: a -> IO Int; reset :: a -> IO ()', alternatively corresponds to `exists a. (a,a -> IO Int,a -> IO ())' |
| 2020-11-18 20:40:30 | × | kritzefitz_ quits (~kritzefit@212.86.56.80) (Read error: Connection reset by peer) |
| 2020-11-18 20:40:35 | → | knupfer joins (~Thunderbi@200116b8244bd600401750fffecef6b8.dip.versatel-1u1.de) |
| 2020-11-18 20:40:53 | → | kritzefitz joins (~kritzefit@212.86.56.80) |
| 2020-11-18 20:40:54 | × | kritzefitz quits (~kritzefit@212.86.56.80) (Client Quit) |
| 2020-11-18 20:41:00 | <dolio> | You can tell most OO folks don't care about the smalltalk perspective, because if they did, they'd be all about proper tail calls. |
| 2020-11-18 20:41:02 | × | knupfer quits (~Thunderbi@200116b8244bd600401750fffecef6b8.dip.versatel-1u1.de) (Remote host closed the connection) |
All times are in UTC.