Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 .. 5022
— 502,152 events total
2020-11-20 11:14:25 × jonatanb quits (jonatanb@gateway/vpn/protonvpn/jonatanb) (Ping timeout: 240 seconds)
2020-11-20 11:17:15 × wei2912 quits (~wei2912@unaffiliated/wei2912) (Remote host closed the connection)
2020-11-20 11:18:24 → Franciman joins (~francesco@host-79-27-199-238.retail.telecomitalia.it)
2020-11-20 11:19:46 × solonarv quits (~solonarv@astrasbourg-653-1-156-4.w90-6.abo.wanadoo.fr) (Quit: Lost terminal)
2020-11-20 11:21:37 × rprije quits (~rprije@124.148.131.132) (Ping timeout: 265 seconds)
2020-11-20 11:22:58 → solonarv joins (~solonarv@astrasbourg-653-1-156-4.w90-6.abo.wanadoo.fr)
2020-11-20 11:23:47 → falafel_ joins (~falafel@2601:547:1303:b30:7811:313f:d0f3:f9f4)
2020-11-20 11:25:04 → gproto23 joins (~gproto23@unaffiliated/gproto23)
2020-11-20 11:27:56 → cosimone joins (~cosimone@2001:b07:ae5:db26:d821:4868:b9f6:2909)
2020-11-20 11:28:14 → sszark joins (~sszark@h-213-180.A392.priv.bahnhof.se)
2020-11-20 11:28:25 → invaser joins (~Thunderbi@31.148.23.125)
2020-11-20 11:28:43 ← vilpan parts (~0@212.117.1.172) ()
2020-11-20 11:29:44 <sszark> I'm extending an existing module by re-exporting it along with my own additions. Is there a way to export the whole scope in a module instead of declaring everything?
2020-11-20 11:30:17 <tdammers> yes. you can do whole-module reexports
2020-11-20 11:30:28 <tdammers> module Foo where (module Bar); import Bar
2020-11-20 11:31:46 × cosimone quits (~cosimone@2001:b07:ae5:db26:d821:4868:b9f6:2909) (Client Quit)
2020-11-20 11:32:27 × falafel_ quits (~falafel@2601:547:1303:b30:7811:313f:d0f3:f9f4) (Ping timeout: 260 seconds)
2020-11-20 11:33:00 → cosimone joins (~cosimone@2001:b07:ae5:db26:d821:4868:b9f6:2909)
2020-11-20 11:33:16 × oish quits (~charlie@228.25.169.217.in-addr.arpa) (Ping timeout: 240 seconds)
2020-11-20 11:33:38 <ClaudiusMaximus> can you do module Foo where (module Bar, module Foo) ; import Bar ; foo = 3 -- to export everything from Foo too? i haven't tested...
2020-11-20 11:35:05 → climber joins (3d044c81@61.4.76.129)
2020-11-20 11:35:35 × cosimone quits (~cosimone@2001:b07:ae5:db26:d821:4868:b9f6:2909) (Client Quit)
2020-11-20 11:35:38 <tdammers> IIRC yes
2020-11-20 11:35:54 → cosimone joins (~cosimone@93-47-228-249.ip115.fastwebnet.it)
2020-11-20 11:36:00 <ski> Martinsos : i think it's good to think of it as first considering sum/variant types (with pattern-matching) ("FP") vs. product/record types (with "message-dispatching") ("OO"), these two being more directly comparable
2020-11-20 11:37:25 × pong quits (chiya@2406:3003:2077:2341::babe) (Ping timeout: 272 seconds)
2020-11-20 11:38:07 → heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net)
2020-11-20 11:39:17 → alp joins (~alp@2a01:e0a:58b:4920:d884:ceaa:fae:7708)
2020-11-20 11:40:02 × Yumasi quits (~guillaume@2a01cb09b06b29eabd8cf63c98e88a0f.ipv6.abo.wanadoo.fr) (Ping timeout: 260 seconds)
2020-11-20 11:42:16 × heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds)
2020-11-20 11:43:50 → pong joins (chiya@2406:3003:2077:2341::babe)
2020-11-20 11:44:26 × pong quits (chiya@2406:3003:2077:2341::babe) (Max SendQ exceeded)
2020-11-20 11:45:29 → pong joins (chiya@2406:3003:2077:2341::babe)
2020-11-20 11:46:08 × pong quits (chiya@2406:3003:2077:2341::babe) (Max SendQ exceeded)
2020-11-20 11:47:36 → Guest31037 joins (chiya@2406:3003:2077:2341::babe)
2020-11-20 11:47:58 Guest31037 is now known as cawfee
2020-11-20 11:49:21 → m0rphism joins (~m0rphism@HSI-KBW-095-208-098-207.hsi5.kabel-badenwuerttemberg.de)
2020-11-20 11:49:32 <sszark> thank you tdammers ClaudiusMaximus
2020-11-20 11:51:05 → jonatanb joins (jonatanb@gateway/vpn/protonvpn/jonatanb)
2020-11-20 11:55:19 × In0perable quits (~PLAYER_1@fancydata.science) (Quit: All your buffer are belong to us!)
2020-11-20 11:55:25 × jonatanb quits (jonatanb@gateway/vpn/protonvpn/jonatanb) (Ping timeout: 240 seconds)
2020-11-20 11:59:06 → Alleria_ joins (~AllahuAkb@69.202.254.168)
2020-11-20 12:00:23 → sMuNiX joins (~sMuNiX@vlnsm8-montreal02-142-122-8-233.internet.virginmobile.ca)
2020-11-20 12:01:56 × coot quits (~coot@37.30.49.253.nat.umts.dynamic.t-mobile.pl) (Quit: coot)
2020-11-20 12:07:51 → olligobber joins (olligobber@gateway/vpn/privateinternetaccess/olligobber)
2020-11-20 12:11:26 <merijn> sszark, ClaudiusMaximus: In fact you can even import only *part* of Foo and re-export that part
2020-11-20 12:11:54 → bitmagie joins (~Thunderbi@200116b8063a3200b470a8e4f2a94e1e.dip.versatel-1u1.de)
2020-11-20 12:13:48 × gxt quits (~gxt@gateway/tor-sasl/gxt) (Remote host closed the connection)
2020-11-20 12:15:18 <Martinsos> ski: I didn't quite get where you are getting with this, would you mind giving me more details/context? How would that fit into deciding how to represent those Shapes / expressin problem?
2020-11-20 12:15:46 <dexterfoo> Is "ViewPatterns" GHC extension good?
2020-11-20 12:16:25 <ski> dexterfoo : it can be useful, sometimes
2020-11-20 12:16:47 → jrm joins (~jrm@freebsd/developer/jrm)
2020-11-20 12:17:01 → gxt joins (~gxt@gateway/tor-sasl/gxt)
2020-11-20 12:17:28 <ski> (avoiding an explicit `case'. being able to fall-through to a later defining equation, if the "secondary" match fails)
2020-11-20 12:18:59 × bitmagie quits (~Thunderbi@200116b8063a3200b470a8e4f2a94e1e.dip.versatel-1u1.de) (Quit: bitmagie)
2020-11-20 12:19:53 <ski> Martinsos : consider your type `Shape'. you want shapes to come in different alternative variants, such as circle,rectangle,&c. and you also want shapes to have various properties like perimeter,area,&c.
2020-11-20 12:21:08 <Martinsos> ski: exactly, we want them to have some common interface, but also to be able to work with them individually. I think we can add that we also want to be able to put them all together in a list.
2020-11-20 12:21:25 <ski> so, for each alternative kind of shape, you need to have an implementation of each property. imagine schematically displaying this in a table. the rows are your different alternatives, the columns are your different properties
2020-11-20 12:22:15 <Martinsos> ski: sure, makes sense
2020-11-20 12:24:12 → p-core joins (~Thunderbi@2001:718:1e03:5128:2ab7:7f35:48a1:8515)
2020-11-20 12:24:34 <ski> the "OO" approach, the product/record types approach, is to slice your table into separate rows. each row becomes a function (a "constructor" in OO terms), that takes whatever parameters the alternative requires (like radius, or width & height), and returns a record with one implementation for each property (each "method"). in OO terminology, this is a class (with a class constructor taking tha parameters)
2020-11-20 12:24:40 <ski> that implements the `Shape' interface (or inherits from the (hopefully abstract) base class `Shape', if you must)
2020-11-20 12:25:26 → LKoen joins (~LKoen@169.244.88.92.rev.sfr.net)
2020-11-20 12:25:42 × climber quits (3d044c81@61.4.76.129) (Remote host closed the connection)
2020-11-20 12:25:57 <Martinsos> ski: Sure, still following! Sorry I will stop writing, if I don't write anything it means I am following :D
2020-11-20 12:25:59 <ski> the "FP" approach, the sum/variant types approach, is to slice your table into separate columns. each column (each property) becomes a pattern-matching function that checks which alternative kind of shape it's given, and computes the property for that case
2020-11-20 12:26:41 <Martinsos> Aha got it
2020-11-20 12:27:03 <ski> the alternatives becomes the data constructors of your sum / variant / algebraic data type
2020-11-20 12:27:11 <Martinsos> And while product approach is more natural / nicer for OO, sum/variatns approach is more natural/nicer for FP?
2020-11-20 12:27:43 <Martinsos> We could say that first one groups logic by variant, whiel second one groups logic by operation?
2020-11-20 12:28:25 <ski> now, in the "OO" approach, if you want to add another kind of alternative, that's easy, just define a new record-producing operation / define a new OO class. but if you want to add another property, now you must edit all the existing classes
2020-11-20 12:28:40 ← pjb parts (~t@2a01cb04063ec500fcb709f072569e15.ipv6.abo.wanadoo.fr) ("ERC (IRC client for Emacs 27.1)")
2020-11-20 12:29:13 <ski> while, in the "FP" approach, if you want to add another property, that's easy, you just define a new pattern-matching function. but if you want to add another alternative, you now have to edit all the existing pattern-matching functions
2020-11-20 12:30:48 <Martinsos> ski: I knew about the extendibility perspective, but what I didn't know is that one is considered OO approach while another is considered FP approach. I get it that that is also incorrect, to call them like that, but it does give an interesting perspective.
2020-11-20 12:30:52 → FreeBirdLjj joins (~freebirdl@101.228.42.108)
2020-11-20 12:31:38 <Martinsos> ski: But to me implementing "OO" approach in Haskell doesn't seem much harder, we can do it with type classes right? Although it does require more code so I guess that makes it less elegant and therefore the variant approach is more of a "FP" approach?
2020-11-20 12:31:38 <ski> Martinsos : exercise : define (FP) a sum type `ShapeS' with alternatives `CircleS',`RectangleS', and pattern-matching functions `perimeterS',`areaS'. then define (OO) a product type `ShapeP' with fields `perimeterP',`areaP' and record-consatructing operations `circleP',`rectangleP'
2020-11-20 12:32:15 <ski> note that if you want a property/method that takes additional parameters, that's just a field that's a function
2020-11-20 12:32:37 <Martinsos> ski: Ok here you are basically implementing type classes manually right?
2020-11-20 12:33:28 × da39a3ee5e6b4b0d quits (~da39a3ee5@2403:6200:8876:6c06:f0fd:283a:1f37:de16) (Read error: Connection reset by peer)
2020-11-20 12:33:44 <Martinsos> ski: Thanks, I get the examples! I have been playing with both examples previously so I did try them in practice, but I was still wondering is, which one is better, if one does not have a ton of information on how the codebase will evolve? I guess the "FP" is simpler and therefore maybe preferred as the first try.
2020-11-20 12:33:51 <ski> also note that pattern-matching allows you to match on nested patterns, and on multiple parallel patterns, not just a single level of alternatives. also, if you throw recursive types into the mix, it can get more interesting/complicated. but the above should hopefully showoff the basic duality between sum types and product types
2020-11-20 12:34:09 → hyperisco joins (~hyperisco@d192-186-117-226.static.comm.cgocable.net)
2020-11-20 12:34:16 → mputz joins (~Thunderbi@dslb-084-058-211-084.084.058.pools.vodafone-ip.de)
2020-11-20 12:34:50 <ski> it's not about either one or the other, you want to have both available to you. sometimes one is more appropriate, sometimes the other. sometimes you can envisage alternatives being changed or added to (or removed from) more often than properties. sometimes the other way around
2020-11-20 12:35:10 × FreeBirdLjj quits (~freebirdl@101.228.42.108) (Ping timeout: 246 seconds)
2020-11-20 12:35:33 × cfricke quits (~cfricke@unaffiliated/cfricke) (Quit: WeeChat 2.9)
2020-11-20 12:36:18 <Martinsos> ski: Thanks for detailed explanation, it is clearer now!
2020-11-20 12:36:46 → Entertainment joins (~entertain@104.246.132.210)
2020-11-20 12:37:03 <Martinsos> ski: for the Shape problem, which one would you use? If you don't know in which direction you will be adding more (operations or variants)? Probably with sum type since it is simpler and we don't have info for either?
2020-11-20 12:37:25 <ski> Martinsos : "And while product approach is more natural / nicer for OO, sum/variatns approach is more natural/nicer for FP?" -- FP languages have tended to emphasize sum types more. it seems it's only now that sum types with pattern-matching are starting to seep out into more mainstream languages. for a long time, there's been an OO dogma that using `switch' or `instanceof' is bad (and the latter is bad, i'd
2020-11-20 12:37:31 <ski> argue. but the motivation for wanting to use it is valid, the problem people want to address is real)
2020-11-20 12:38:25 → Tario joins (~Tario@201.192.165.173)
2020-11-20 12:39:55 <ski> and so, you've gotten the VisitorPattern for (clumsily & verbosily) simulating/encoding sum types with pattern-matching, in OO. it's basically just a CPS / Church encoding of sum types. `A + B' being encoded as `forall o. (A -> o) * (B -> o) -> o'. `(A -> o) * (B -> o)' is the visitor, it's the branches of a `case'-`of', packaged up together
2020-11-20 12:40:11 × daim2k5 quits (~daim2k5@185.204.1.185) (Remote host closed the connection)
2020-11-20 12:41:20 → enoq joins (~textual@194-208-146-143.lampert.tv)
2020-11-20 12:41:30 <ski> Martinsos : "We could say that first one groups logic by variant, whiel second one groups logic by operation?" -- yes (although the way i'm using the term "operation" is more like in the Abstract Data Type sense. so i'd probably say "property"/"method" instead of "operation", in your characterization)
2020-11-20 12:43:59 <ski> "one is considered OO approach while another is considered FP approach. I get it that that is also incorrect, to call them like that, but it does give an interesting perspective." -- they're crude terms, there's more to FP and OO than this. but it does place the finger on some important differences between how both tends to be used, and it's a quick way to get the point across. if someone already understands
2020-11-20 12:44:05 <ski> what are product/record types, and what are sum/variant types, then i'd probably prefer using those terms instead of "OO" and "FP"
2020-11-20 12:44:27 <joel135> . o O (interaction laws https://youtu.be/LHIKGC_oxFA?t=801)
←Prev  Next→
Page 1 .. 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 .. 5022

All times are in UTC.