2025/02/12

Newest at the top

2025-02-12 18:58:19 +0100zungi(~tory@user/andrewchawk) andrewchawk
2025-02-12 18:53:21 +0100zungi(~tory@user/andrewchawk) (Quit: "Moving to other building...")
2025-02-12 18:52:59 +0100 <hololeap> weird. this works in 9.4 but in 9.8 it just causes my exe to spin forever: https://stackoverflow.com/a/41055988
2025-02-12 18:51:54 +0100Smiles(uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2025-02-12 18:48:51 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2025-02-12 18:47:50 +0100sord937(~sord937@gateway/tor-sasl/sord937) (Quit: sord937)
2025-02-12 18:47:22 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-02-12 18:46:14 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 260 seconds)
2025-02-12 18:44:38 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-02-12 18:41:53 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-12 18:36:02 +0100byorgey(~byorgey@user/byorgey) byorgey
2025-02-12 18:36:02 +0100byorgey(~byorgey@155.138.238.211) (Changing host)
2025-02-12 18:36:02 +0100byorgey(~byorgey@155.138.238.211)
2025-02-12 18:35:47 +0100 <geekosaur> I still think the Report is the wrong place for it, implementations should be able to make their own decisions. ghc is kinda wrong in deferring it to library docs instead of compiler docs though
2025-02-12 18:33:30 +0100tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net)
2025-02-12 18:31:50 +0100haritz(~hrtz@user/haritz) haritz
2025-02-12 18:31:50 +0100haritz(~hrtz@2a02:8010:65b5:0:5d9a:9bab:ee5e:b737) (Changing host)
2025-02-12 18:31:48 +0100haritz(~hrtz@2a02:8010:65b5:0:5d9a:9bab:ee5e:b737)
2025-02-12 18:31:31 +0100 <monochrom> Hey, vote for me to be the absolute monarch, then I will make it happen! >:)
2025-02-12 18:31:24 +0100 <EvanR> that provides an authoritative answer to my question
2025-02-12 18:30:49 +0100 <monochrom> So basically the Report bitrots and all the clarifications happen in library docs instead.
2025-02-12 18:30:31 +0100JuanDaugherty(~juan@user/JuanDaugherty) (Exeunt DS Producers)
2025-02-12 18:30:13 +0100 <EvanR> that is almost the latest version of unicode being linked too
2025-02-12 18:30:09 +0100 <monochrom> It would have been entered into a new version of the Report, if only people bothered to form a committee for it.
2025-02-12 18:29:24 +0100 <geekosaur> "The character type Char represents Unicode codespace and its elements are code points as in definitions D9 and D10 of the Unicode Standard."
2025-02-12 18:29:14 +0100 <monochrom> \∩/
2025-02-12 18:28:47 +0100 <geekosaur> oh, I found it. even though it's necessarily a compiler built-in, it's specified in library documentation https://downloads.haskell.org/ghc/latest/docs/libraries/base-4.21.0.0-8e62/Data-Char.html#t:Char
2025-02-12 18:28:19 +0100 <EvanR> practically it seems to be in one to one correspondence with integers in the precise range of unicode's... codes
2025-02-12 18:27:37 +0100 <geekosaur> (which is a shocking amount once you start digging into it…)
2025-02-12 18:27:35 +0100 <monochrom> I don't have absolute certainty that Char = codepoint, but I use that as a working theory and it works pretty well.
2025-02-12 18:27:22 +0100 <geekosaur> but then you have to understand all the stuff the Report didn't specify
2025-02-12 18:27:10 +0100 <EvanR> turns out once you understand what (latest) unicode is, Char makes less sense xD
2025-02-12 18:26:55 +0100Wygulmage(~Wygulmage@user/Wygulmage) (Quit: Client closed)
2025-02-12 18:26:46 +0100 <monochrom> To understand what Char is, first you have to understand what Unicode is. >:)
2025-02-12 18:26:38 +0100 <EvanR> which is how C considers characters
2025-02-12 18:26:32 +0100saimazoon(~hrtz@user/haritz) (Ping timeout: 252 seconds)
2025-02-12 18:26:08 +0100 <EvanR> which is an integer, or codepoint. So "a fancy integer" seems yeah
2025-02-12 18:25:42 +0100 <EvanR> like fffe
2025-02-12 18:25:16 +0100 <EvanR> are literally not characters
2025-02-12 18:25:01 +0100 <EvanR> and other non-characters
2025-02-12 18:22:44 +0100 <geekosaur> but, strictly speaking, is wrong because surrogates are not characters
2025-02-12 18:21:40 +0100prasad(~Thunderbi@c-73-75-25-251.hsd1.in.comcast.net)
2025-02-12 18:21:15 +0100 <EvanR> "a unicode character" was probably written back in the day, unicode since clarified what a character is (in several ways), but it ends up still making sense
2025-02-12 18:21:07 +0100 <geekosaur> it could have been designrd differently: UTF-8 doesn't have the same problem, it just ends up with potentially long encodings (IIRC up to 7, although in practice not more than 3-4 because the rest haven't been assigned yet?)
2025-02-12 18:20:22 +0100sarna(~sarna@d168-237.icpnet.pl) sarna
2025-02-12 18:20:17 +0100 <EvanR> if I'm not mistaken
2025-02-12 18:19:45 +0100 <EvanR> the issue would have been some code points could not be encoded with UTF-16 if some codepoints weren't blocked out
2025-02-12 18:19:40 +0100econo_(uid147250@id-147250.tinside.irccloud.com)
2025-02-12 18:19:17 +0100sarna(~sarna@d168-237.icpnet.pl) (Remote host closed the connection)
2025-02-12 18:17:56 +0100JuanDaugherty(~juan@user/JuanDaugherty) JuanDaugherty