Logs: freenode/#haskell
| 2021-03-22 08:56:44 | × | danza quits (~francesco@151.53.91.117) (Quit: Leaving) |
| 2021-03-22 08:57:36 | → | Vadrigar joins (~Vadrigar@ip5b417208.dynamic.kabel-deutschland.de) |
| 2021-03-22 09:00:03 | × | __minoru__shirae quits (~shiraeesh@109.166.57.171) (Ping timeout: 260 seconds) |
| 2021-03-22 09:03:28 | → | Major_Biscuit joins (~Major_Bis@82-169-100-198.biz.kpn.net) |
| 2021-03-22 09:04:44 | → | ph88 joins (~ph88@2a02:8109:9e00:7e5c:f4a3:f661:850c:269d) |
| 2021-03-22 09:04:55 | → | wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-03-22 09:05:03 | × | is_null quits (~jpic@pdpc/supporter/professional/is-null) (Ping timeout: 245 seconds) |
| 2021-03-22 09:05:06 | × | pjb quits (~t@2a01cb04063ec50019789bb8481aa192.ipv6.abo.wanadoo.fr) (Ping timeout: 265 seconds) |
| 2021-03-22 09:05:24 | × | Cerato quits (~Cerberus@185.207.164.90) (Quit: The Lounge - https://thelounge.chat) |
| 2021-03-22 09:05:38 | → | Cerato joins (~Cerberus@185.207.164.90) |
| 2021-03-22 09:06:30 | → | idhugo__ joins (~idhugo@80-62-117-136-mobile.dk.customer.tdc.net) |
| 2021-03-22 09:08:46 | → | hiroaki joins (~hiroaki@2a02:8108:8c40:2bb8:3517:3251:7569:53c5) |
| 2021-03-22 09:08:48 | × | idhugo_ quits (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Ping timeout: 246 seconds) |
| 2021-03-22 09:08:48 | → | idhugo joins (~idhugo@130.225.16.16) |
| 2021-03-22 09:09:01 | → | v01d4lph4 joins (~v01d4lph4@223.190.38.71) |
| 2021-03-22 09:10:13 | × | wroathe quits (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 265 seconds) |
| 2021-03-22 09:11:08 | × | idhugo__ quits (~idhugo@80-62-117-136-mobile.dk.customer.tdc.net) (Ping timeout: 260 seconds) |
| 2021-03-22 09:11:46 | v01d4lph4 | is now known as silent_freak |
| 2021-03-22 09:11:56 | silent_freak | is now known as v01d4lph4 |
| 2021-03-22 09:13:16 | v01d4lph4 | is now known as silent_freak |
| 2021-03-22 09:13:20 | silent_freak | is now known as v01d4lph4 |
| 2021-03-22 09:15:30 | × | v01d4lph4 quits (~v01d4lph4@223.190.38.71) () |
| 2021-03-22 09:15:44 | × | malumore quits (~malumore@151.62.119.219) (Ping timeout: 240 seconds) |
| 2021-03-22 09:15:46 | → | v01d4lph4 joins (~v01d4lph4@223.190.38.71) |
| 2021-03-22 09:20:53 | × | azure1 quits (~azure@103.154.230.130) (Ping timeout: 245 seconds) |
| 2021-03-22 09:21:31 | × | davidfetter1 quits (~davidfett@217.146.82.202) (Remote host closed the connection) |
| 2021-03-22 09:22:14 | × | Major_Biscuit quits (~Major_Bis@82-169-100-198.biz.kpn.net) (Quit: WeeChat 3.0.1) |
| 2021-03-22 09:24:05 | → | Pickchea joins (~private@unaffiliated/pickchea) |
| 2021-03-22 09:27:36 | → | malumore joins (~malumore@151.62.119.219) |
| 2021-03-22 09:28:34 | <tdammers> | could also be a matter of using network line endings |
| 2021-03-22 09:31:27 | → | __monty__ joins (~toonn@unaffiliated/toonn) |
| 2021-03-22 09:34:08 | × | stree quits (~stree@68.36.8.116) (Ping timeout: 240 seconds) |
| 2021-03-22 09:35:38 | → | wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-03-22 09:36:05 | → | azure1 joins (~azure@103.154.230.130) |
| 2021-03-22 09:37:35 | → | Guest12366 joins (~sdx23@139.28.218.148) |
| 2021-03-22 09:38:55 | → | raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-03-22 09:39:16 | → | pjb joins (~t@2a01cb04063ec50048893e58a8f103cd.ipv6.abo.wanadoo.fr) |
| 2021-03-22 09:40:38 | × | wroathe quits (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 256 seconds) |
| 2021-03-22 09:41:44 | → | Major_Biscuit joins (~Major_Bis@82-169-100-198.biz.kpn.net) |
| 2021-03-22 09:42:04 | → | aarvar joins (~foewfoiew@2601:602:a080:fa0:75fb:cea1:4d26:9157) |
| 2021-03-22 09:42:14 | → | LKoen joins (~LKoen@194.250.88.92.rev.sfr.net) |
| 2021-03-22 09:43:38 | × | plutoniix quits (~q@184.82.200.84) (Read error: Connection reset by peer) |
| 2021-03-22 09:43:47 | → | royal_screwup21 joins (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) |
| 2021-03-22 09:46:01 | → | plutoniix joins (~q@184.82.200.84) |
| 2021-03-22 09:47:13 | → | Aquazi joins (uid312403@gateway/web/irccloud.com/x-zekuiaehstzprzsn) |
| 2021-03-22 09:47:24 | → | stree joins (~stree@68.36.8.116) |
| 2021-03-22 09:48:08 | × | azure1 quits (~azure@103.154.230.130) (Ping timeout: 240 seconds) |
| 2021-03-22 09:48:32 | → | heatsink joins (~heatsink@2600:1700:bef1:5e10:90f:37ea:5699:98fc) |
| 2021-03-22 09:50:25 | → | frozenErebus joins (~frozenEre@94.128.81.87) |
| 2021-03-22 09:51:07 | → | timCF joins (~i.tkachuk@200-149-20-81.sta.estpak.ee) |
| 2021-03-22 09:51:24 | → | marinelli joins (~marinelli@gateway/tor-sasl/marinelli) |
| 2021-03-22 09:51:32 | → | azure1 joins (~azure@103.154.230.130) |
| 2021-03-22 09:53:07 | → | thc202 joins (~thc202@unaffiliated/thc202) |
| 2021-03-22 09:53:07 | × | heatsink quits (~heatsink@2600:1700:bef1:5e10:90f:37ea:5699:98fc) (Ping timeout: 260 seconds) |
| 2021-03-22 09:54:34 | <timCF> | Hello! Recently I've played with lexing/parsing libraries in Haskell, and discovered that some people are using `Alex` + `Happy` and some other people are using `Parsec`. Are `Alex` + `Happy` and `Parsec` just different libraries made for the same purpose/usecase? Or they do specialize on different things? How to decide what to use? |
| 2021-03-22 09:57:13 | <Uniaika> | timCF: Alex+Happy are for "Parser generation", whilst Parsec/Megaparsec/Attoparsec are parser combinator libraries |
| 2021-03-22 09:57:32 | <merijn> | timCF: Alex and Happy are parser generators in the lex/yacc and flex/bison tradition |
| 2021-03-22 09:57:33 | × | idhugo quits (~idhugo@130.225.16.16) (Read error: Connection reset by peer) |
| 2021-03-22 09:57:52 | <merijn> | Parsec and its ilk are parser combinators libraries and more like eDSLs for writing parsers |
| 2021-03-22 09:58:57 | → | idhugo joins (~idhugo@80-62-117-136-mobile.dk.customer.tdc.net) |
| 2021-03-22 09:59:27 | <merijn> | timCF: Parser generators will, generally, produce more efficient parsers (or, more accurately, they can guarantee that efficiency) while parser combinator libraries are probably easier to get started with |
| 2021-03-22 09:59:51 | <merijn> | timCF: Fighting an LALR(1) parser generator is...not fun if you just wanna get something done :p |
| 2021-03-22 10:01:12 | <timCF> | I actually did tried Alex+Happy, as excercise with "Modern Compiler Implementation in ML" book. But didn't tried Parsec. |
| 2021-03-22 10:01:42 | <merijn> | timCF: Does the term "recursive descent parser" mean anything to you? |
| 2021-03-22 10:03:01 | <timCF> | I've just did parser for Tiger programming language, using Alex. Defined AST types, defined lexemes regex, transitions between states. |
| 2021-03-22 10:03:25 | <timCF> | But sounds like the same task can be done with Parsec, right? |
| 2021-03-22 10:03:42 | <merijn> | Sure |
| 2021-03-22 10:03:54 | <timCF> | And preference "what is easier/better" is very personal? |
| 2021-03-22 10:03:56 | <merijn> | timCF: I mean, you can do *any* parsing task with parsec |
| 2021-03-22 10:05:27 | <timCF> | merijn: thanks for reply! |
| 2021-03-22 10:05:28 | <__monty__> | timCF: Note that Parsec is old and superceded by Megaparsec (or Attoparsec if you insist) pretty much. Trifecta's also an interesting take on parsing. |
| 2021-03-22 10:05:32 | <merijn> | timCF: Recursive descent parser are an easy way to get started with parsing. They allow for unbounded lookahead, so that makes them easy for weird grammars, but unbounded look ahead also has performance implications. Meanwhile LALR(1) parser generators guarantee max 1 item of lookahead. But that can make adapting a grammar to LALR(1) a PITA |
| 2021-03-22 10:06:21 | <merijn> | timCF: There is no fundamental reason that a well-written recursive descent parser would be slower than, say, an LALR(1) generated parser. But writing *good* recursive descent parser may be harder then just using LALR(1) |
| 2021-03-22 10:06:27 | → | wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-03-22 10:06:48 | <merijn> | timCF: Realistically speaking, for "human-sized" source files (max a few thousand lines per file) the performance isn't gonna matter either way |
| 2021-03-22 10:06:57 | <merijn> | Disk IO will take longer than parsing :p |
| 2021-03-22 10:08:47 | → | mananamenos joins (~mananamen@62.red-88-11-67.dynamicip.rima-tde.net) |
| 2021-03-22 10:09:08 | → | fendor joins (~fendor@178.165.131.239.wireless.dyn.drei.com) |
| 2021-03-22 10:09:09 | → | jamm_ joins (~jamm@unaffiliated/jamm) |
| 2021-03-22 10:10:06 | → | heatsink joins (~heatsink@2600:1700:bef1:5e10:90f:37ea:5699:98fc) |
| 2021-03-22 10:11:18 | × | wroathe quits (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 245 seconds) |
| 2021-03-22 10:11:58 | → | Gurkenglas joins (~Gurkengla@unaffiliated/gurkenglas) |
| 2021-03-22 10:12:52 | → | elfets joins (~elfets@ip-37-201-23-96.hsi13.unitymediagroup.de) |
| 2021-03-22 10:12:58 | → | Rudd0 joins (~Rudd0@185.189.115.108) |
| 2021-03-22 10:13:20 | × | jamm_ quits (~jamm@unaffiliated/jamm) (Ping timeout: 240 seconds) |
| 2021-03-22 10:14:18 | → | acidjnk_new joins (~acidjnk@p200300d0c72b9545dcff5306019ad0b1.dip0.t-ipconnect.de) |
| 2021-03-22 10:14:26 | × | heatsink quits (~heatsink@2600:1700:bef1:5e10:90f:37ea:5699:98fc) (Ping timeout: 264 seconds) |
| 2021-03-22 10:14:56 | <mananamenos> | Hi, is it normal to have something like `newtype App a = App (ReaderT Env M a)` and an extra class with a method which would lift `M` to `App`, so that one could do `M` actions inside `App`? |
| 2021-03-22 10:15:38 | <Rembane> | mananamenos: Normal I don't know, but it's definitely a way to handle monad transformer stacks. |
| 2021-03-22 10:16:11 | <merijn> | The normal way to handle monad transformers is hide them away in a newtype like that and not expose their existence :p |
| 2021-03-22 10:18:02 | → | Mrbuck joins (~Mrbuck@gateway/tor-sasl/mrbuck) |
| 2021-03-22 10:19:47 | × | zaquest quits (~notzaques@5.128.210.178) (Quit: Leaving) |
| 2021-03-22 10:20:46 | ← | rkrishnan parts (~rkrishnan@rkrishnan.org) ("ERC (IRC client for Emacs 27.1)") |
| 2021-03-22 10:22:56 | × | azure1 quits (~azure@103.154.230.130) (Ping timeout: 240 seconds) |
| 2021-03-22 10:24:07 | <mananamenos> | Rembane, merijn, so regarding my example if I come to such a situacion (where I want do `M` stuff inside `App` monad) it show that I have designed my data type wrong? I shouldnt want/need to use underlying monad's (in this case `M`) actions inside my App? |
| 2021-03-22 10:25:06 | × | Pickchea quits (~private@unaffiliated/pickchea) (Ping timeout: 246 seconds) |
| 2021-03-22 10:25:28 | <merijn> | mananamenos: The more experience I get with big code bases, the more I'm convinced that "exposing the fact that something is a transformer stack (or it's internals)" is a mistake |
| 2021-03-22 10:25:48 | → | azure1 joins (~azure@103.154.230.130) |
| 2021-03-22 10:26:16 | → | zaquest joins (~notzaques@5.128.210.178) |
| 2021-03-22 10:26:25 | <Rembane> | merijn: Why is it a mistake? |
All times are in UTC.