Logs: freenode/#haskell
| 2021-04-21 10:38:00 | → | Alleria joins (~textual@mskresolve-a.mskcc.org) |
| 2021-04-21 10:38:01 | → | minoru_shiraeesh joins (~shiraeesh@109.166.59.151) |
| 2021-04-21 10:38:23 | Alleria | is now known as Guest92203 |
| 2021-04-21 10:39:33 | → | heatsink joins (~heatsink@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-04-21 10:42:31 | × | CiaoSen quits (~Jura@p200300c9572bc100dd00e68a577d428e.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2021-04-21 10:42:38 | → | ericsagnes joins (~ericsagne@2405:6580:0:5100:dde9:bfa7:6f37:dd87) |
| 2021-04-21 10:42:47 | × | bitmagie quits (~Thunderbi@200116b8063572001499edd4f9d505b9.dip.versatel-1u1.de) (Quit: bitmagie) |
| 2021-04-21 10:43:04 | → | Kaeipi joins (~Kaiepi@47.54.252.148) |
| 2021-04-21 10:43:41 | × | heatsink quits (~heatsink@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2021-04-21 10:44:19 | × | Kaiepi quits (~Kaiepi@47.54.252.148) (Remote host closed the connection) |
| 2021-04-21 10:46:44 | × | quinn quits (~quinn@c-73-223-224-163.hsd1.ca.comcast.net) (Quit: ZNC 1.8.1 - https://znc.in) |
| 2021-04-21 10:48:40 | → | tatsumaru joins (~tatsumaru@85.196.189.103) |
| 2021-04-21 10:49:21 | <tatsumaru> | hey guys, the book I am reading claims the keyword 'let' is necessary for defining variables, but in ghci it seems that variables work without 'let' either. is let optional at this point or maybe I am not understanding the point? |
| 2021-04-21 10:49:35 | <merijn> | tatsumaru: ghci is a hack |
| 2021-04-21 10:49:38 | → | aVikingTrex joins (~aVikingTr@2001:8003:340d:d00:b2de:b98:7a93:b0ea) |
| 2021-04-21 10:50:05 | <merijn> | tatsumaru: Also, the book might be wrong/misleading, depending on context |
| 2021-04-21 10:50:21 | <tatsumaru> | merjin, what did you mean by ghci being a hack |
| 2021-04-21 10:50:26 | <merijn> | tatsumaru: You only need let-in to define variables *in an expression* context |
| 2021-04-21 10:50:53 | <merijn> | tatsumaru: ghci's commandline is halfway in between "acts like top level of a file" and "acts like an expression context" |
| 2021-04-21 10:51:28 | <tatsumaru> | so it doesn't evaluate code the same way the compiler would? |
| 2021-04-21 10:52:07 | <merijn> | tatsumaru: Lets rewind a whole bit |
| 2021-04-21 10:52:30 | <merijn> | tatsumaru: In a module context, you can define bindings (variables, if you will) by simply defining "x = ..." |
| 2021-04-21 10:53:14 | <merijn> | tatsumaru: But that only (I'm handwaving here) works at the module or some specific contexts where you are allowed to define bindings |
| 2021-04-21 10:53:45 | <merijn> | tatsumaru: "let-in" is a way to create a context to define bindings within an expression |
| 2021-04-21 10:53:58 | <merijn> | > (let x = 5 in 2 * x) + 10 |
| 2021-04-21 10:54:00 | <lambdabot> | 20 |
| 2021-04-21 10:54:57 | <merijn> | tatsumaru: So let isn't necessary for defining variables at all. Let is just a way to define variables in places where you normally can't |
| 2021-04-21 10:55:16 | → | sagax joins (~sagax_nb@213.138.71.146) |
| 2021-04-21 10:55:16 | <merijn> | i.e. you can't normally write "(x = 5) + 10" because what does that even mean? |
| 2021-04-21 10:55:34 | <tatsumaru> | so basically it's for reassuring the compiler that you want to define a binding? |
| 2021-04-21 10:55:52 | → | philderbeast joins (~textual@bras-base-vldvpq5901w-grc-06-184-144-244-252.dsl.bell.ca) |
| 2021-04-21 10:59:26 | → | heatsink joins (~heatsink@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-04-21 11:00:05 | <merijn> | Not really? |
| 2021-04-21 11:00:22 | <merijn> | tatsumaru: Any programming languages you're already familiar with? |
| 2021-04-21 11:00:26 | → | cfricke joins (~cfricke@unaffiliated/cfricke) |
| 2021-04-21 11:00:51 | <tatsumaru> | not really, I am just starting out in programming with haskell |
| 2021-04-21 11:01:12 | × | guest421` quits (~user@47.245.54.240) (Ping timeout: 240 seconds) |
| 2021-04-21 11:01:25 | <Logio> | I think there used to be a time when ghci did not accept variable definitions without a preceding let (i.e. it just operated with things valid in a IO do-block) |
| 2021-04-21 11:02:19 | <merijn> | Correct |
| 2021-04-21 11:02:25 | × | gehmehgeh quits (~ircuser1@gateway/tor-sasl/gehmehgeh) (Remote host closed the connection) |
| 2021-04-21 11:02:36 | <merijn> | But it is unclear whether the book in question was referring to "defining variables in ghci" or "in general" |
| 2021-04-21 11:02:54 | <merijn> | In other words: Insufficient context to understand where the confusion is coming from |
| 2021-04-21 11:03:44 | × | shailangsa quits (~shailangs@host86-185-102-48.range86-185.btcentralplus.com) (Ping timeout: 246 seconds) |
| 2021-04-21 11:03:48 | → | gehmehgeh joins (~ircuser1@gateway/tor-sasl/gehmehgeh) |
| 2021-04-21 11:04:02 | <tatsumaru> | merjin this is what it says: "Note: We can use the let keyword to define a name right in GHCI. Doing let a = 1 inside GHCI is the equivalent of writing a = 1 in a script and then loading it." |
| 2021-04-21 11:04:11 | × | heatsink quits (~heatsink@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 252 seconds) |
| 2021-04-21 11:04:34 | <tatsumaru> | but then I noticed that I could do a = 1 in GHCI as well so I wondered if let was obsolete |
| 2021-04-21 11:05:05 | <merijn> | Ah |
| 2021-04-21 11:05:52 | <merijn> | Yeah, you used to need to use let for variables (and commands for loading modules) in gchi, because ghci behaved like a "weird interactive IO monad do-block" |
| 2021-04-21 11:06:15 | <merijn> | tatsumaru: But at some point around GHC 8 it got changed to support import statements and direct bindings too |
| 2021-04-21 11:06:24 | <tatsumaru> | is it fair to say that ghci is like repl? |
| 2021-04-21 11:06:45 | <merijn> | tatsumaru: Which is what I meant with ghci being a hack, it behaves sorta like a weird mix between "proper module syntax" and "dynamic do block" |
| 2021-04-21 11:06:59 | <merijn> | tatsumaru: ghci *is* a repl :p |
| 2021-04-21 11:07:08 | <merijn> | it reads, it evaluates, it prints and loops back ;) |
| 2021-04-21 11:07:17 | <tatsumaru> | got it, thanks a lot :) |
| 2021-04-21 11:08:02 | <merijn> | tatsumaru: It's just weird in that it *also* accepts expressions (like "2 + 5") which is a syntax error in source files |
| 2021-04-21 11:09:36 | → | boogsbunny joins (17520e19@23.82.14.25) |
| 2021-04-21 11:13:16 | × | xff0x quits (~xff0x@2001:1a81:5253:e800:1dc:184f:3c23:9adc) (Ping timeout: 245 seconds) |
| 2021-04-21 11:14:05 | → | xff0x joins (~xff0x@2001:1a81:5253:e800:55a6:95d0:743f:3c74) |
| 2021-04-21 11:15:12 | × | olligobber quits (olligobber@gateway/vpn/privateinternetaccess/olligobber) (Ping timeout: 240 seconds) |
| 2021-04-21 11:15:34 | → | jumper149 joins (~jumper149@80.240.31.34) |
| 2021-04-21 11:16:18 | <kuribas> | it distinguishes between IO expressions, other expressions, and declarations. |
| 2021-04-21 11:16:37 | <kuribas> | declarations used to be not even supported. |
| 2021-04-21 11:16:51 | <merijn> | That's what we just said? |
| 2021-04-21 11:17:09 | <merijn> | tbh, I still think adding support for top level bindings/imports just makes ghci *more* confusing |
| 2021-04-21 11:17:15 | <kuribas> | right, it was supported using let |
| 2021-04-21 11:17:47 | <kuribas> | merijn: maybe, but it's very convenient |
| 2021-04-21 11:17:59 | <kuribas> | you can quickly define and test data types |
| 2021-04-21 11:18:01 | <tomsmeding> | ^ |
| 2021-04-21 11:18:15 | <merijn> | Death by minor conveniences is a common problem in tech |
| 2021-04-21 11:18:28 | <tomsmeding> | ghci exists for convenience |
| 2021-04-21 11:18:32 | <tomsmeding> | hot take |
| 2021-04-21 11:18:41 | <kuribas> | I remember when there was a lot of demand for it :) |
| 2021-04-21 11:18:43 | <merijn> | If you just keep post hoc piling on more "minor convenience features" eventually things become unusable piles of mess |
| 2021-04-21 11:18:48 | → | __monty__ joins (~toonn@unaffiliated/toonn) |
| 2021-04-21 11:19:10 | <kuribas> | merijn: really, the REPL IS for quick and dirty testing. |
| 2021-04-21 11:19:27 | <merijn> | So? |
| 2021-04-21 11:19:33 | <tomsmeding> | and for IDE-like functionality, which falls under the same category |
| 2021-04-21 11:19:34 | <merijn> | Doesn't mean it can't have a consistent design |
| 2021-04-21 11:19:37 | <kuribas> | so it can be quick and dirty :) |
| 2021-04-21 11:19:41 | <merijn> | Disagree |
| 2021-04-21 11:20:03 | <merijn> | Dirty hacks attract dirty hacks |
| 2021-04-21 11:20:42 | <tomsmeding> | I guess it would be nice if ghci had a consistent interface on top of which the convenience syntax is implemented |
| 2021-04-21 11:21:26 | <tomsmeding> | would that be better? |
| 2021-04-21 11:22:46 | → | rekahsoft joins (~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com) |
| 2021-04-21 11:22:53 | <tatsumaru> | maybe there should be different repls for different people who have different goals/intentions |
| 2021-04-21 11:24:42 | → | stef204 joins (~stef204@unaffiliated/stef-204/x-384198) |
| 2021-04-21 11:25:08 | <tomsmeding> | indeed if ghci had a consistent interface on top of which the "convenience" syntaxes were defined, then making such different repls wouldn't be too hard :) |
| 2021-04-21 11:25:22 | <tomsmeding> | and it's also nice from a software engineering standpoint |
| 2021-04-21 11:26:01 | <[exa]> | still, somehow, after many years we've only got the one ghci frontend :] |
| 2021-04-21 11:27:23 | exarkun_ | is now known as exarkun |
| 2021-04-21 11:28:23 | → | shailangsa joins (~shailangs@host217-42-54-186.range217-42.btcentralplus.com) |
| 2021-04-21 11:28:34 | <tomsmeding> | it seems to work for most people |
| 2021-04-21 11:29:07 | <tatsumaru> | is there a new haskell 2020 spec coming soon or is this a myth? |
| 2021-04-21 11:29:15 | <tomsmeding> | myth |
| 2021-04-21 11:29:21 | <merijn> | lol |
| 2021-04-21 11:29:25 | <merijn> | Myth :p |
| 2021-04-21 11:29:37 | <tatsumaru> | why is the official wiki claiming there's a 2020 preview release |
| 2021-04-21 11:29:38 | <tomsmeding> | ghc has a "GHC2021" language that is equivalent to a number of commonly-used GHC language extensions |
| 2021-04-21 11:29:43 | <tomsmeding> | is it? |
All times are in UTC.