2026/03/04

2026-03-04 00:01:00 +0100shr\ke(~shrike@user/shrke:31298) (Ping timeout: 245 seconds)
2026-03-04 00:01:53 +0100humasect(~humasect@dyn-192-249-132-90.nexicom.net) (Quit: Leaving...)
2026-03-04 00:04:44 +0100humasect(~humasect@dyn-192-249-132-90.nexicom.net) humasect
2026-03-04 00:04:48 +0100kilolympus6(~kilolympu@vmi1102682.contaboserver.net) kilolympus
2026-03-04 00:04:59 +0100kilolympus(~kilolympu@vmi1102682.contaboserver.net) (Read error: Connection reset by peer)
2026-03-04 00:04:59 +0100kilolympus6kilolympus
2026-03-04 00:08:18 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-03-04 00:10:59 +0100peterbecich(~Thunderbi@71.84.33.135) (Ping timeout: 265 seconds)
2026-03-04 00:11:16 +0100shr\ke(~shrike@user/paxhumana) paxhumana
2026-03-04 00:11:16 +0100shr\ke(~shrike@user/paxhumana) (Changing host)
2026-03-04 00:11:16 +0100shr\ke(~shrike@user/shrke:31298) shr\ke
2026-03-04 00:11:53 +0100__monty__(~toonn@user/toonn) (Quit: leaving)
2026-03-04 00:13:31 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-03-04 00:15:53 +0100tromp(~textual@2001:1c00:3487:1b00:bca6:b25a:741d:ca28) (Quit: My iMac has gone to sleep. ZZZzzz…)
2026-03-04 00:19:45 +0100 <yin> int-e: nice. you're extracting values from a pair with `c :: (Word -> Word) -> Word` right? that's equivalent to my `pre`
2026-03-04 00:20:47 +0100 <int-e> yin: that's where it came from
2026-03-04 00:22:07 +0100 <yin> did you derive it? it took me a long time to understand your version (it also took me a long time to understand mine)
2026-03-04 00:22:52 +0100 <int-e> I've seen the lambda term before. I'm quite familiar with some of the themes around Church numerals.
2026-03-04 00:23:35 +0100mange(~mange@user/mange) (Quit: Bye!)
2026-03-04 00:24:06 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-03-04 00:24:35 +0100 <int-e> I think the best I've ever come up with myself was pred = \n f x -> n (\c a b -> c b (f b)) (\a b -> a) x x
2026-03-04 00:24:40 +0100gmg(~user@user/gehmehgeh) (Quit: Leaving)
2026-03-04 00:24:43 +0100 <yin> is this technically cps? it feels like cps
2026-03-04 00:25:41 +0100 <int-e> There are definitely continuations here. (That's why I like calling the argument 'c'. Though I messed up above; \c -> 0 should've been \f -> 0; it is a continuation but the argument isn't)
2026-03-04 00:28:34 +0100gmg(~user@user/gehmehgeh) gehmehgeh
2026-03-04 00:29:07 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-03-04 00:31:21 +0100 <yin> this is great
2026-03-04 00:39:54 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-03-04 00:41:48 +0100emmanuelux(~em@user/emmanuelux) emmanuelux
2026-03-04 00:44:04 +0100ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 245 seconds)
2026-03-04 00:46:19 +0100 <monochrom> I prefer "k" to "c". :)
2026-03-04 00:46:30 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds)
2026-03-04 00:47:48 +0100 <int-e> Hi monokhrom
2026-03-04 00:47:55 +0100 <monochrom> haha
2026-03-04 00:50:34 +0100 <yin> > take 10 $ ($ id) <$> iterate (\c f -> f (c succ)) (const 0)
2026-03-04 00:50:36 +0100 <lambdabot> [0,0,1,2,3,4,5,6,7,8]
2026-03-04 00:50:45 +0100 <monochrom> kontinuashun https://lambdacats.github.io/delimited/
2026-03-04 00:51:21 +0100 <EvanR> yin, at the very least, define the missing operations with an error message denoting who to blame
2026-03-04 00:51:32 +0100 <EvanR> is ワ lowercase or uppercase for the purposes of haskell?
2026-03-04 00:51:53 +0100 <chromoblob> monochrom: neat
2026-03-04 00:51:55 +0100 <int-e> > isLower 'ワ'
2026-03-04 00:51:56 +0100 <lambdabot> False
2026-03-04 00:52:03 +0100 <yin> EvanR: I mostly blame the Num typeclass itself
2026-03-04 00:52:04 +0100 <EvanR> it's pretty big so seems like a constructor
2026-03-04 00:52:04 +0100 <int-e> > isUpper 'ワ'
2026-03-04 00:52:05 +0100 <lambdabot> False
2026-03-04 00:52:14 +0100 <chromoblob> ...
2026-03-04 00:52:21 +0100 <int-e> > let ワ = 1 in ワ
2026-03-04 00:52:22 +0100 <lambdabot> 1
2026-03-04 00:52:31 +0100 <int-e> EvanR: I guess this makes it "lower case"
2026-03-04 00:52:59 +0100 <int-e> I hope it isn't anything offensive ;)
2026-03-04 00:53:16 +0100 <int-e> wah!
2026-03-04 00:53:19 +0100int-eruns
2026-03-04 00:53:29 +0100 <chromoblob> > (not . isUpper) 'ワ' -- here, fixed :p
2026-03-04 00:53:31 +0100 <lambdabot> True
2026-03-04 00:54:04 +0100 <int-e> % data ワ = ワ
2026-03-04 00:54:04 +0100 <yahb2> <interactive>:19:10: error: [GHC-25742] Not a data constructor: ‘ワ’
2026-03-04 00:54:25 +0100 <int-e> % data Xワ = Xワ
2026-03-04 00:54:25 +0100 <yahb2> <no output>
2026-03-04 00:54:31 +0100Square(~Square@user/square) (Ping timeout: 276 seconds)
2026-03-04 00:54:34 +0100 <int-e> (that looks so wrong)
2026-03-04 00:54:39 +0100 <chromoblob> % data ワ = Wa
2026-03-04 00:54:39 +0100 <yahb2> <interactive>:23:6: error: [GHC-47568] ; Malformed head of type or class declaration: ワ
2026-03-04 00:54:56 +0100 <EvanR> so it's like, yes upper is required for constructors
2026-03-04 00:55:04 +0100 <EvanR> lower is not required for variables
2026-03-04 00:55:35 +0100 <EvanR> the plot thickens
2026-03-04 00:55:52 +0100 <geekosaur> yes and always has been. one of the annoyances with Haskell given scripts that lack the distinction (kanji, katakana, hangul, Arabic, Hebrew, etc.)
2026-03-04 00:56:11 +0100 <geekosaur> initial upper for constructors, lower (or neutral) for variables
2026-03-04 00:56:30 +0100 <geekosaur> ":" is treated as an "uppercase" symbol character
2026-03-04 00:56:48 +0100 <yin> > generalCategory 'ワ'
2026-03-04 00:56:49 +0100 <lambdabot> OtherLetter
2026-03-04 00:57:56 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-03-04 00:59:17 +0100 <int-e> EvanR: The Haskell 2010 report assumes a dichotomy with language like, for example, "Names for variables and type variables are identifiers beginning with lowercase letters or underscore; the other four kinds of names are identifiers beginning with uppercase letters." So this is technically a GHC extension? Hehe.
2026-03-04 00:59:31 +0100 <EvanR> if you write out some computer text containing latin, green, chinese, arabic, and hebrew, some of these scripts will appear "big" and some "small"... that's how it should've been divided between types, ctors and variables xD
2026-03-04 00:59:37 +0100 <EvanR> s/green/greek/
2026-03-04 00:59:44 +0100 <geekosaur> > generalCategory 'ש'
2026-03-04 00:59:45 +0100 <lambdabot> OtherLetter
2026-03-04 01:00:48 +0100 <chromoblob> > generalCategory '☉'
2026-03-04 01:00:49 +0100 <lambdabot> OtherSymbol
2026-03-04 01:00:55 +0100 <EvanR> but then I guess chinese would be stuck without variables
2026-03-04 01:01:13 +0100 <int-e> > generalCategory 'ꙮ'
2026-03-04 01:01:14 +0100 <lambdabot> OtherLetter
2026-03-04 01:01:17 +0100 <geekosaur> it's kinda stuck without constructors
2026-03-04 01:01:23 +0100 <EvanR> it's fine because obviously variables like x y and z
2026-03-04 01:01:27 +0100 <chromoblob> > let x ☉ y = -(x * y) in 2 ☉ 3
2026-03-04 01:01:28 +0100 <lambdabot> -6
2026-03-04 01:01:33 +0100 <EvanR> are supposed to look like xD
2026-03-04 01:01:35 +0100 <chromoblob> cool...
2026-03-04 01:01:57 +0100Sgeo(~Sgeo@user/sgeo) Sgeo
2026-03-04 01:02:19 +0100 <EvanR> whoever heard of a variable not latin or greek
2026-03-04 01:02:28 +0100 <EvanR> ok there was the soviet programming language
2026-03-04 01:02:47 +0100 <chromoblob> i'm still waiting for the syntax "a `(b `c` d)` e"...
2026-03-04 01:02:50 +0100 <yin> . o O ( APL )
2026-03-04 01:03:19 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-03-04 01:03:52 +0100 <int-e> > let (ο,o,о) = (1,2,3) in ο + o + о + ο
2026-03-04 01:03:53 +0100 <lambdabot> 7
2026-03-04 01:04:10 +0100 <chromoblob> lol
2026-03-04 01:04:15 +0100 <yin> what
2026-03-04 01:04:22 +0100 <chromoblob> different o's
2026-03-04 01:04:35 +0100 <yin> scared me for a moment
2026-03-04 01:04:45 +0100 <chromoblob> heh
2026-03-04 01:04:52 +0100 <geekosaur> > generalCategory '𝐱'
2026-03-04 01:04:53 +0100 <lambdabot> LowercaseLetter
2026-03-04 01:05:50 +0100 <geekosaur> chromoblob: not gonna happen, nightmare to parse those nested backticks and in general backticked expressions
2026-03-04 01:06:05 +0100 <geekosaur> if they'd chosen a different closing character it would have been easier
2026-03-04 01:06:17 +0100 <geekosaur> consider string parsing
2026-03-04 01:06:26 +0100 <yin> i wish `f` was just 'f or even `f would be fine
2026-03-04 01:06:42 +0100 <geekosaur> plan 9 user? 😛
2026-03-04 01:07:37 +0100 <yin> whitespace as application would be great too
2026-03-04 01:08:05 +0100 <int-e> x ◖infix◗ y
2026-03-04 01:08:05 +0100 <chromoblob> why would it be a nightmare?
2026-03-04 01:08:46 +0100 <EvanR> imagine if strings could be nested without escaping the "
2026-03-04 01:08:54 +0100 <EvanR> lol
2026-03-04 01:08:56 +0100 <geekosaur> go look at why the Bourne shell's backrticks were replaced with `$()`
2026-03-04 01:09:08 +0100 <geekosaur> because those _did_ nest
2026-03-04 01:09:16 +0100 <geekosaur> (well, with escapes)
2026-03-04 01:09:46 +0100 <EvanR> "abc "def" ghi"
2026-03-04 01:09:48 +0100 <yin> x `w `f` z` y
2026-03-04 01:09:55 +0100 <geekosaur> even with escapes it was really hard to deal with; without, well, I'm sure you could get a lexer to handle it but $* help the reader
2026-03-04 01:10:25 +0100 <geekosaur> and do remember that code is written to be readable by humans, not the computer. if we cared about the computer reading it we'd still be keying programs in in hex