Logs: freenode/#haskell
| 2021-05-08 17:27:33 | × | jb55 quits (~jb55@gateway/tor-sasl/jb55) (Ping timeout: 240 seconds) |
| 2021-05-08 17:28:36 | → | zebrag joins (~inkbottle@aaubervilliers-654-1-99-167.w86-212.abo.wanadoo.fr) |
| 2021-05-08 17:29:50 | → | danvet joins (~Daniel@2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa) |
| 2021-05-08 17:31:07 | × | nbloomf quits (~nbloomf@2600:1700:ad14:3020:1c47:1620:4713:95a3) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-05-08 17:31:26 | × | ddellacosta quits (~ddellacos@ool-44c73afa.dyn.optonline.net) (Ping timeout: 265 seconds) |
| 2021-05-08 17:31:55 | × | electricityZZZZ quits (~electrici@157-131-250-97.fiber.dynamic.sonic.net) (Ping timeout: 265 seconds) |
| 2021-05-08 17:32:16 | → | neiluj joins (~jco@91-167-203-101.subs.proxad.net) |
| 2021-05-08 17:32:16 | × | neiluj quits (~jco@91-167-203-101.subs.proxad.net) (Changing host) |
| 2021-05-08 17:32:16 | → | neiluj joins (~jco@unaffiliated/neiluj) |
| 2021-05-08 17:32:31 | × | jgt_ quits (~jgt@92-247-237-116.spectrumnet.bg) (Ping timeout: 260 seconds) |
| 2021-05-08 17:33:03 | → | cmburnett joins (~Charlie_B@c-73-37-184-31.hsd1.mn.comcast.net) |
| 2021-05-08 17:34:25 | × | jamm_ quits (~jamm@unaffiliated/jamm) (Remote host closed the connection) |
| 2021-05-08 17:34:58 | <cmburnett> | Stupid question but what's GHC doing when you reassign a variable with "let"? Wouldn't that be mutable? |
| 2021-05-08 17:35:03 | → | jamm_ joins (~jamm@unaffiliated/jamm) |
| 2021-05-08 17:35:37 | <ski> | no |
| 2021-05-08 17:35:45 | <ski> | there's no variable assignment |
| 2021-05-08 17:36:26 | <ski> | `let' introduces a new binding, which will shadow any existing outer binding of an identifier with the same name |
| 2021-05-08 17:36:56 | <maerwald> | maybe the question was about what happens in the generated assembly? |
| 2021-05-08 17:37:11 | <ski> | also, note that `let' bindings are recursive. so, if you e.g. do `let x = x + 1', then this is a recursive definition (in this case, an infinite loop) |
| 2021-05-08 17:37:25 | ski | looks at cmburnett |
| 2021-05-08 17:37:41 | maerwald | looks at ski |
| 2021-05-08 17:37:46 | × | DTZUZU quits (~DTZUZO@205.ip-149-56-132.net) (Ping timeout: 252 seconds) |
| 2021-05-08 17:38:00 | ski | looks everywhere, except at maerwald |
| 2021-05-08 17:38:05 | <maerwald> | :D |
| 2021-05-08 17:38:11 | <cmburnett> | *** looks in mirror, confused |
| 2021-05-08 17:38:16 | <cmburnett> | A bit of both actually! Sorry, new to haskell but I'm more of a low level C guy |
| 2021-05-08 17:38:53 | <maerwald> | hmm... I don't know what happens in the generated code, but that's not something you should generally be considered about |
| 2021-05-08 17:39:05 | <cmburnett> | Is it essentially just a new variable with a different address, then subsequent references look at the new one? |
| 2021-05-08 17:39:29 | × | jamm_ quits (~jamm@unaffiliated/jamm) (Ping timeout: 250 seconds) |
| 2021-05-08 17:39:34 | <maerwald> | I'd even go so far to say that won't help your understanding of the language |
| 2021-05-08 17:39:35 | <monochrom> | new variable. shadowing name-wise. |
| 2021-05-08 17:39:47 | <ski> | yes .. although i don't think it's that useful to think of it in terms of "address" (of an object) at all. think in terms of values, not (mutable) objects |
| 2021-05-08 17:39:51 | → | DTZUZU joins (~DTZUZO@207.81.119.43) |
| 2021-05-08 17:39:56 | <Rembane> | Values and names. |
| 2021-05-08 17:40:09 | <ski> | when the scope of the `let' ends, the outer variable will be visible again |
| 2021-05-08 17:40:13 | <maerwald> | The way GHC deals with this case my arbitrarily change |
| 2021-05-08 17:40:33 | <maerwald> | important is only the language semantics |
| 2021-05-08 17:40:48 | <ski> | > let x = 2 in (let x = 3 in x*x) + x -- `x' is `3' in `x*x', but in the `+ x' part at the end, `x' refers to the outer variable, which is `2' |
| 2021-05-08 17:40:50 | <lambdabot> | 11 |
| 2021-05-08 17:41:12 | <cmburnett> | ah alright that makes sense, thanks! |
| 2021-05-08 17:41:19 | <superstar64> | cmburnett forget what an address is, this is a high level language |
| 2021-05-08 17:41:36 | <ski> | C also has block scoping with local identifiers shadowing non-local ones |
| 2021-05-08 17:41:39 | × | xff0x quits (~xff0x@2001:1a81:52ef:f00:8213:5fa0:2f9f:9160) (Ping timeout: 250 seconds) |
| 2021-05-08 17:42:00 | <maerwald> | superstar64: heh |
| 2021-05-08 17:42:38 | <superstar64> | even in c, your variables might not have address after optimization |
| 2021-05-08 17:42:41 | <monochrom> | C is neither low-level nor high-level. C is an attic embarrassment. https://queue.acm.org/detail.cfm?id=3212479 |
| 2021-05-08 17:42:43 | → | xff0x joins (~xff0x@2001:1a81:52ef:f00:5daf:a79:257d:70d5) |
| 2021-05-08 17:43:16 | <monochrom> | C was cool in its historical context, but that context doesn't exist any more. |
| 2021-05-08 17:43:36 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 260 seconds) |
| 2021-05-08 17:43:46 | <maerwald> | don't be a heretic |
| 2021-05-08 17:43:47 | <ski> | { int x = 2,y,z; { int x = 2; y = x*x; } z = y + x; } /* this is somewhat similar, in C, to the above Haskell example. `z' will end up having value `11' */ |
| 2021-05-08 17:43:56 | → | ddellaco_ joins (~ddellacos@ool-44c73afa.dyn.optonline.net) |
| 2021-05-08 17:43:57 | <ski> | cmburnett ^ |
| 2021-05-08 17:44:08 | <geekosaur> | C was cool when the alternative was MS-BASIC |
| 2021-05-08 17:44:29 | × | DTZUZU quits (~DTZUZO@207.81.119.43) (Ping timeout: 265 seconds) |
| 2021-05-08 17:44:36 | <Rembane> | I dunno about that, I like C as a high level assembler dialect. |
| 2021-05-08 17:44:40 | <maerwald> | C is what molds the programmers weak will into a strong, resilient, pain-resistent mind |
| 2021-05-08 17:44:48 | <cmburnett> | ... i mean, isn't ghc C based? |
| 2021-05-08 17:45:08 | <monochrom> | No. |
| 2021-05-08 17:45:19 | <superstar64> | ghc is written in haskell |
| 2021-05-08 17:45:30 | <monochrom> | Precisely because C doesn't even do justice to "high-level assembler". |
| 2021-05-08 17:45:31 | → | jgt_ joins (~jgt@92-247-237-116.spectrumnet.bg) |
| 2021-05-08 17:45:33 | <cmburnett> | right but I mean it outputs C I thought |
| 2021-05-08 17:45:33 | <maerwald> | we still have a legacy C backend though I think |
| 2021-05-08 17:45:37 | <maerwald> | no |
| 2021-05-08 17:45:41 | <geekosaur> | parts of the runtime are written in cmm, which is that higher level assembler (and not C0 |
| 2021-05-08 17:45:52 | <geekosaur> | it used to output C years ago |
| 2021-05-08 17:45:59 | <maerwald> | it's legacy |
| 2021-05-08 17:46:04 | <ski> | it was a long time since compilation via C was the default |
| 2021-05-08 17:46:28 | <geekosaur> | and that C had to be compiled to asm and then a script run over it to make it suitable for use |
| 2021-05-08 17:46:29 | × | coot quits (~coot@37.30.58.122.nat.umts.dynamic.t-mobile.pl) (Quit: coot) |
| 2021-05-08 17:46:32 | <monochrom> | And when GHC did compile to C, it was not purely that, it had to run a Perl script to rewrite the asm. |
| 2021-05-08 17:46:34 | <maerwald> | although there are good reasons to keep C backend (formal verification, for instance) |
| 2021-05-08 17:46:36 | <monochrom> | Precisely because C doesn't even do justice to "high-level assembler". |
| 2021-05-08 17:46:40 | <ski> | @quote mangler |
| 2021-05-08 17:46:41 | <lambdabot> | Pseudonym says: All hail the Evil Mangler! |
| 2021-05-08 17:46:53 | × | rayyyy quits (~nanoz@gateway/tor-sasl/nanoz) (Quit: Leaving) |
| 2021-05-08 17:47:25 | → | snowflake joins (~snowflake@gateway/tor-sasl/snowflake) |
| 2021-05-08 17:47:29 | <cmburnett> | huh, the more you know |
| 2021-05-08 17:47:55 | <monochrom> | If it doesn't expose the carry flag it is not high-level assembly. |
| 2021-05-08 17:48:10 | × | frozenErebus quits (~frozenEre@37.231.244.249) (Ping timeout: 268 seconds) |
| 2021-05-08 17:48:11 | <cmburnett> | it uses the llvm-ir now then? |
| 2021-05-08 17:48:13 | <monochrom> | If it doesn't let you manipulate the stack it is not high-level assembly. |
| 2021-05-08 17:48:13 | <superstar64> | monochrom, well what other options are there for portable assembly? none of them are as stable and wide spread as c |
| 2021-05-08 17:48:36 | <cmburnett> | wait nevermind, cmm right |
| 2021-05-08 17:48:36 | × | rajivr quits (uid269651@gateway/web/irccloud.com/x-ckqjpzirevusuqkn) (Quit: Connection closed for inactivity) |
| 2021-05-08 17:49:12 | <geekosaur> | llvm-ir is one of the possible cmm targets |
| 2021-05-08 17:49:17 | <ski> | cmburnett : anyway, unless you're specifically concerned about implementation details (note that your `let' question didn't seem to be about this, but about semantics), you probably should ask about Haskell, not GHC |
| 2021-05-08 17:49:42 | <Rembane> | monochrom: Now we're getting into the gray areas. You have to use inline assembly to do all the fun stuff in C, but it's very easy to do so as long as there's only one target platform. |
| 2021-05-08 17:49:51 | × | ddellaco_ quits (~ddellacos@ool-44c73afa.dyn.optonline.net) (Ping timeout: 252 seconds) |
| 2021-05-08 17:50:30 | → | ddellaco_ joins (~ddellacos@ool-44c73afa.dyn.optonline.net) |
| 2021-05-08 17:51:07 | × | ddellaco_ quits (~ddellacos@ool-44c73afa.dyn.optonline.net) (Remote host closed the connection) |
| 2021-05-08 17:51:08 | <cmburnett> | i was actually concerned mostly with implementation, i've been working on a language/compiler and was curious how it was generally handled |
| 2021-05-08 17:51:17 | <monochrom> | Rembane, I would be OK with s/high-level assembly/low-level algol/ |
| 2021-05-08 17:51:47 | <monochrom> | C is algol but exposes address arithmetic and struct memory layout |
| 2021-05-08 17:51:48 | <superstar64> | cmburnett https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/hsc-main |
| 2021-05-08 17:51:58 | <monochrom> | That's still not high-level assembly. |
| 2021-05-08 17:52:06 | → | ddellaco_ joins (~ddellacos@ool-44c73afa.dyn.optonline.net) |
| 2021-05-08 17:53:12 | <cmburnett> | superstar64: thanks that's super helpful for what i'm trying to do! |
| 2021-05-08 17:53:32 | <superstar64> | i'm also making my own programming language |
All times are in UTC.