Logs: liberachat/#haskell
| 2021-07-16 01:46:28 | <dsal> | Ah, I've never used `toCaseFold`. I understand why now. :) |
| 2021-07-16 01:52:49 | × | Null_A quits (~null_a@2601:645:8700:2290:187e:cdbe:3584:806) (Remote host closed the connection) |
| 2021-07-16 01:53:12 | <Clint> | because you have no reason to? |
| 2021-07-16 01:53:59 | ← | jakalx parts (~jakalx@base.jakalx.net) (Error from remote client) |
| 2021-07-16 01:54:30 | → | Null_A joins (~null_a@2601:645:8700:2290:187e:cdbe:3584:806) |
| 2021-07-16 01:54:54 | × | gzj quits (~GZJ0X@199.193.127.138.16clouds.com) (Ping timeout: 255 seconds) |
| 2021-07-16 01:56:21 | <oso> | ...should i not be using it? |
| 2021-07-16 01:56:22 | × | Vajb quits (~Vajb@2001:999:62:1d53:26b1:6c9b:c1ed:9c01) (Read error: Connection reset by peer) |
| 2021-07-16 01:57:00 | → | Vajb joins (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-16 01:57:16 | <geekosaur> | Ideally you use the text-icu package and include locale information |
| 2021-07-16 01:57:29 | × | oxide quits (~lambda@user/oxide) (Ping timeout: 268 seconds) |
| 2021-07-16 01:57:31 | <geekosaur> | capitalization turns out to be incredibly tricky |
| 2021-07-16 01:57:46 | × | ph88^ quits (~ph88@2a02:8109:9e00:7e5c:9925:18b1:79f7:f242) (Ping timeout: 268 seconds) |
| 2021-07-16 01:58:18 | → | jakalx joins (~jakalx@base.jakalx.net) |
| 2021-07-16 01:59:49 | → | oxide joins (~lambda@user/oxide) |
| 2021-07-16 02:01:05 | <oso> | wow thanks, text-icu looks very useful |
| 2021-07-16 02:02:53 | × | smichel17 quits (~smichel17@c-73-68-217-18.hsd1.ma.comcast.net) (Quit: smichel17) |
| 2021-07-16 02:04:48 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 255 seconds) |
| 2021-07-16 02:06:23 | <dsal> | oso: It depends on what you're doing. As Clint inferred, I've not had a reason to use it, but your use case might need it. Not sure what you're doing. |
| 2021-07-16 02:08:06 | <Guest21> | How well does GHC optimize the use of lists? |
| 2021-07-16 02:08:07 | <Guest21> | For example, if I have the code |
| 2021-07-16 02:08:07 | <Guest21> | main = forM_ [1,3..10] $ print |
| 2021-07-16 02:08:08 | <Guest21> | will GHC need to put a list in memory to use this code, or will it be optimized to the equivalent of: |
| 2021-07-16 02:08:08 | <Guest21> | int main (void){ |
| 2021-07-16 02:08:09 | <Guest21> | for(int i = 1; i <= 10; i += 2) |
| 2021-07-16 02:08:09 | <Guest21> | printf("%d\n", i); |
| 2021-07-16 02:08:10 | <Guest21> | } |
| 2021-07-16 02:09:37 | <dsal> | Guest21: (please use a paste). What happens if you don't put an upper bound on that? Does it work? |
| 2021-07-16 02:09:53 | <dsal> | Also, that $ is superfluous. |
| 2021-07-16 02:10:58 | <davean> | dsal: I don't feel thats an enlightening question |
| 2021-07-16 02:11:47 | <dsal> | Why's that? |
| 2021-07-16 02:12:00 | <davean> | dsal: It'll definately work when you don't put an upper bound, even if it does create the list |
| 2021-07-16 02:12:17 | <davean> | That has nothing to do with optimization, and everything to do with Haskell being non-strict |
| 2021-07-16 02:12:30 | <dsal> | I see what you mean. |
| 2021-07-16 02:12:30 | <davean> | So the answer to it in no way addresses their question |
| 2021-07-16 02:13:13 | <dsal> | Other than "read core" what's a better way to answer that? |
| 2021-07-16 02:13:39 | <Axman6> | Guest21: you can answer that yourself by replacing 10 with 100000000 and seeing if memory usage increases. you can probably also answer it yourrself by looking at the implementation of enumFromThenTo and forM_ and seeing how fprM_ (enumFromThenT1 3 10) print evaluates |
| 2021-07-16 02:13:58 | <Axman6> | @src enumFromThenTo |
| 2021-07-16 02:13:58 | <lambdabot> | Source not found. My pet ferret can type better than you! |
| 2021-07-16 02:14:02 | <davean> | Axman6: GC will grab it as you walk the list |
| 2021-07-16 02:14:16 | <davean> | Axman6: You'd have to read the rules at best |
| 2021-07-16 02:14:28 | <davean> | and I think thats a core part of the question - different optimization levels will do different things |
| 2021-07-16 02:14:39 | <davean> | Guest21: even reifing the list, it'll be faster than I expect you think BTW |
| 2021-07-16 02:14:46 | <davean> | Guest21: because it is a bump pointer |
| 2021-07-16 02:14:48 | <Axman6> | I can pretty much guarantee no list will ever exist as each value is generated lazily |
| 2021-07-16 02:15:08 | × | raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 272 seconds) |
| 2021-07-16 02:15:16 | → | elf_fortrez joins (~elf_fortr@adsl-72-50-4-118.prtc.net) |
| 2021-07-16 02:15:29 | <davean> | Axman6: they're generated lazily sure, but at least at -O0 the list *will* exist, you'll just walk up the list as fast as you create it, and it'll be thrown away every nursery GC |
| 2021-07-16 02:15:33 | <davean> | which is VERY cheap |
| 2021-07-16 02:15:37 | <davean> | but that does create a list |
| 2021-07-16 02:15:43 | <davean> | I think sometimes the list will go away |
| 2021-07-16 02:16:02 | <davean> | But I'd have to read core to confirm it - thats not the structure I use for my optimization work so I'm not super familiar with how it compiles down in practice |
| 2021-07-16 02:16:28 | × | td_ quits (~td@94.134.91.92) (Ping timeout: 252 seconds) |
| 2021-07-16 02:16:35 | <elf_fortrez> | why throw away a list? |
| 2021-07-16 02:16:40 | → | myShoggoth joins (~myShoggot@97-120-70-214.ptld.qwest.net) |
| 2021-07-16 02:16:45 | <davean> | elf_fortrez: can you expand that question? |
| 2021-07-16 02:16:45 | <dsal> | I guess part of the problem is what is actually being asked by "will GHC need to put a list in memory to use this code" Before it starts processing? As an output of the action? Or just literally, the equivalent C code. For the last one, you have to read the core. |
| 2021-07-16 02:16:55 | <elf_fortrez> | it is a very versitele data structure |
| 2021-07-16 02:16:59 | FinnElija | is now known as Guest6659 |
| 2021-07-16 02:16:59 | → | finn_elija joins (~finn_elij@user/finn-elija/x-0085643) |
| 2021-07-16 02:16:59 | × | Guest6659 quits (~finn_elij@user/finn-elija/x-0085643) (Killed (strontium.libera.chat (Nickname regained by services))) |
| 2021-07-16 02:16:59 | finn_elija | is now known as FinnElija |
| 2021-07-16 02:17:21 | <dsal> | It's a fine data structure, but this problem doesn't need a data structure. |
| 2021-07-16 02:17:24 | <davean> | elf_fortrez: I feel you didn't follwo the conversation at all - the list is mearly control flow here |
| 2021-07-16 02:17:29 | <elf_fortrez> | is the list persistent in a functional language? |
| 2021-07-16 02:17:39 | <elf_fortrez> | beautiful |
| 2021-07-16 02:17:48 | <dsal> | Oh. I see elf_fortrez entered after the conversation started. :) |
| 2021-07-16 02:18:04 | <davean> | Ah yes they did |
| 2021-07-16 02:18:13 | → | td_ joins (~td@94.134.91.148) |
| 2021-07-16 02:18:15 | <elf_fortrez> | i'm a bit beat up. i just want to wake up |
| 2021-07-16 02:18:45 | <davean> | Guest21: So, it may be a few addition instructions off of C, but it will use some constant memory amount, and it will be pretty close in performance to the C forloop |
| 2021-07-16 02:18:51 | <elf_fortrez> | the concept of a list as control flow is exciting. to good to be true? |
| 2021-07-16 02:18:55 | <davean> | Guest21: there are ways to make sure it is as efficient as the C for loop though |
| 2021-07-16 02:19:19 | → | s_ joins (~s@50.34.81.185) |
| 2021-07-16 02:20:05 | <elf_fortrez> | isn't haskell about beautiful notation and not speed? |
| 2021-07-16 02:20:13 | <davean> | elf_fortrez: "forM_ [1..10] $ something here" uses a list as a very basic control flow for example, theres a general area of study of this I tihnk called co-data? |
| 2021-07-16 02:20:28 | <davean> | elf_fortrez: I've optimized Haskell to be faster than C implimentations plenty of times |
| 2021-07-16 02:20:54 | <elf_fortrez> | I guess Haskell is the bomb |
| 2021-07-16 02:20:54 | <dsal> | elf_fortrez: There's nothing wrong with speed. For some of us, Haskell is our go-to language for most problem solving, so we do both as we go. |
| 2021-07-16 02:21:02 | <davean> | Those "beautiful notions" (you said notation but I'm correcting you) can be a way to get perforamnce |
| 2021-07-16 02:21:16 | <elf_fortrez> | so it's functional |
| 2021-07-16 02:22:13 | <davean> | Yah, I'd say more people code Haskell than know how to use it in production, but I don't think thats all that unusual for a pleasant language to use. |
| 2021-07-16 02:22:25 | <davean> | We could certainly better diseminate the practical sides! |
| 2021-07-16 02:22:38 | <davean> | There are plenty of us who find it one of the most productive options for production. |
| 2021-07-16 02:22:50 | <davean> | Its just not where the excitement seems to tend to be, I guess for obvious reasons. |
| 2021-07-16 02:23:17 | <dsal> | There are fancy features I don't ever get to use because I'm just a blue collar hacker. |
| 2021-07-16 02:23:34 | × | ukari quits (~ukari@user/ukari) (Remote host closed the connection) |
| 2021-07-16 02:24:16 | <davean> | People who do production Haskell tend to shut up and do production Haskell |
| 2021-07-16 02:24:17 | → | ukari joins (~ukari@user/ukari) |
| 2021-07-16 02:24:21 | × | jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 258 seconds) |
| 2021-07-16 02:25:26 | <elf_fortrez> | no need to boast i guess, just educate |
| 2021-07-16 02:28:04 | <elf_fortrez> | how can i write a circle graph in Haskell? |
| 2021-07-16 02:28:13 | <davean> | Haskell Foundation is actively working on trying to diseminate knowlege on that side now |
| 2021-07-16 02:28:15 | <elf_fortrez> | in polar coordinates for kicks |
| 2021-07-16 02:28:16 | <Axman6> | circle graph? |
| 2021-07-16 02:28:25 | <elf_fortrez> | unit circle |
| 2021-07-16 02:28:29 | <davean> | We *have* clearly had a problem educating people on the production side. Its not what people are excited to talk about. |
| 2021-07-16 02:28:37 | <Axman6> | oh, that type of graph |
| 2021-07-16 02:28:50 | <davean> | elf_fortrez: Is this the sort of thing you'd want Diagram for? |
| 2021-07-16 02:29:16 | <elf_fortrez> | thanks for the idea, Venn or Euler would be nice |
All times are in UTC.