Logs: liberachat/#haskell
| 2026-03-03 23:56:11 | <geekosaur> | initial upper for constructors, lower (or neutral) for variables |
| 2026-03-03 23:56:30 | <geekosaur> | ":" is treated as an "uppercase" symbol character |
| 2026-03-03 23:56:48 | <yin> | > generalCategory 'ワ' |
| 2026-03-03 23:56:49 | <lambdabot> | OtherLetter |
| 2026-03-03 23:57:56 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-03 23:59:17 | <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-03 23:59:31 | <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-03 23:59:37 | <EvanR> | s/green/greek/ |
| 2026-03-03 23:59:44 | <geekosaur> | > generalCategory 'ש' |
| 2026-03-03 23:59:45 | <lambdabot> | OtherLetter |
| 2026-03-04 00:00:48 | <chromoblob> | > generalCategory '☉' |
| 2026-03-04 00:00:49 | <lambdabot> | OtherSymbol |
| 2026-03-04 00:00:55 | <EvanR> | but then I guess chinese would be stuck without variables |
| 2026-03-04 00:01:13 | <int-e> | > generalCategory 'ꙮ' |
| 2026-03-04 00:01:14 | <lambdabot> | OtherLetter |
| 2026-03-04 00:01:17 | <geekosaur> | it's kinda stuck without constructors |
| 2026-03-04 00:01:23 | <EvanR> | it's fine because obviously variables like x y and z |
| 2026-03-04 00:01:27 | <chromoblob> | > let x ☉ y = -(x * y) in 2 ☉ 3 |
| 2026-03-04 00:01:28 | <lambdabot> | -6 |
| 2026-03-04 00:01:33 | <EvanR> | are supposed to look like xD |
| 2026-03-04 00:01:35 | <chromoblob> | cool... |
| 2026-03-04 00:01:57 | → | Sgeo joins (~Sgeo@user/sgeo) |
| 2026-03-04 00:02:19 | <EvanR> | whoever heard of a variable not latin or greek |
| 2026-03-04 00:02:28 | <EvanR> | ok there was the soviet programming language |
| 2026-03-04 00:02:47 | <chromoblob> | i'm still waiting for the syntax "a `(b `c` d)` e"... |
| 2026-03-04 00:02:50 | <yin> | . o O ( APL ) |
| 2026-03-04 00:03:19 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-04 00:03:52 | <int-e> | > let (ο,o,о) = (1,2,3) in ο + o + о + ο |
| 2026-03-04 00:03:53 | <lambdabot> | 7 |
| 2026-03-04 00:04:10 | <chromoblob> | lol |
| 2026-03-04 00:04:15 | <yin> | what |
| 2026-03-04 00:04:22 | <chromoblob> | different o's |
| 2026-03-04 00:04:35 | <yin> | scared me for a moment |
| 2026-03-04 00:04:45 | <chromoblob> | heh |
| 2026-03-04 00:04:52 | <geekosaur> | > generalCategory '𝐱' |
| 2026-03-04 00:04:53 | <lambdabot> | LowercaseLetter |
| 2026-03-04 00:05:50 | <geekosaur> | chromoblob: not gonna happen, nightmare to parse those nested backticks and in general backticked expressions |
| 2026-03-04 00:06:05 | <geekosaur> | if they'd chosen a different closing character it would have been easier |
| 2026-03-04 00:06:17 | <geekosaur> | consider string parsing |
| 2026-03-04 00:06:26 | <yin> | i wish `f` was just 'f or even `f would be fine |
| 2026-03-04 00:06:42 | <geekosaur> | plan 9 user? 😛 |
| 2026-03-04 00:07:37 | <yin> | whitespace as application would be great too |
| 2026-03-04 00:08:05 | <int-e> | x ◖infix◗ y |
| 2026-03-04 00:08:05 | <chromoblob> | why would it be a nightmare? |
| 2026-03-04 00:08:46 | <EvanR> | imagine if strings could be nested without escaping the " |
| 2026-03-04 00:08:54 | <EvanR> | lol |
| 2026-03-04 00:08:56 | <geekosaur> | go look at why the Bourne shell's backrticks were replaced with `$()` |
| 2026-03-04 00:09:08 | <geekosaur> | because those _did_ nest |
| 2026-03-04 00:09:16 | <geekosaur> | (well, with escapes) |
| 2026-03-04 00:09:46 | <EvanR> | "abc "def" ghi" |
| 2026-03-04 00:09:48 | <yin> | x `w `f` z` y |
| 2026-03-04 00:09:55 | <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 00:10:25 | <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 |
| 2026-03-04 00:11:04 | <chromoblob> | that's why i used parentheses |
| 2026-03-04 00:11:21 | → | Tuplanolla joins (~Tuplanoll@88-114-89-88.elisa-laajakaista.fi) |
| 2026-03-04 00:11:39 | <geekosaur> | and in Haskell in particular, with its rather finely diced syntax… put soemthing in the wrong place by accident and the error messages would resemble C++ template errors ☺ |
| 2026-03-04 00:13:34 | <yin> | no way, you can nest ``? |
| 2026-03-04 00:13:42 | <geekosaur> | no, this is if you could |
| 2026-03-04 00:13:43 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-04 00:13:51 | <geekosaur> | also if it allowed general expressions |
| 2026-03-04 00:14:48 | <chromoblob> | every backtick enters a backtick mode, in it either an id or an opening paren, latter enters a level and we're in non-backtick again; closing paren checks the level and exits into non-backtick on previous level |
| 2026-03-04 00:15:02 | <int-e> | > let start c = c []; push z x c = c (x:z); add (x:y:z) c = c (x+y:z); end z = z in start push 1 push 2 push 3 add add end -- who needs infix operators anyway |
| 2026-03-04 00:15:04 | <lambdabot> | [6] |
| 2026-03-04 00:16:28 | <yin> | ah, you can leave whitespace between ``..... |
| 2026-03-04 00:16:42 | <yin> | > succ ` fmap ` [0..1] |
| 2026-03-04 00:16:43 | <lambdabot> | [1,2] |
| 2026-03-04 00:17:00 | <yin> | > succ` fmap `[0..2] |
| 2026-03-04 00:17:01 | <lambdabot> | [1,2,3] |
| 2026-03-04 00:17:15 | <yin> | this is not good |
| 2026-03-04 00:17:19 | <EvanR> | it's like * in C >:D |
| 2026-03-04 00:18:11 | <chromoblob> | int-e: wow |
| 2026-03-04 00:18:27 | <int-e> | @quote * |
| 2026-03-04 00:18:27 | <lambdabot> | * says: | shapr remembers that hours of coding can save minutes of thinking |
| 2026-03-04 00:18:37 | <yin> | int-e: yay continuations |
| 2026-03-04 00:18:55 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-04 00:19:25 | <int-e> | yin: if you want to go mildly insane, work out the type of the `start` in there. |
| 2026-03-04 00:19:37 | <chromoblob> | wow |
| 2026-03-04 00:22:08 | <chromoblob> | %type () |
| 2026-03-04 00:22:39 | chromoblob | tried |
| 2026-03-04 00:23:12 | <int-e> | % :type () -- the space is required for yahb2; the : is for ghci |
| 2026-03-04 00:23:12 | <yahb2> | () -- the space is required for yahb2; the : is for ghci :: () |
| 2026-03-04 00:23:46 | <int-e> | @type () -- or this for lambdabot |
| 2026-03-04 00:23:47 | <lambdabot> | () |
| 2026-03-04 00:27:34 | <EvanR> | cool I got the type of start in the first try... at least the most general type xD |
| 2026-03-04 00:29:28 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-04 00:32:00 | <chromoblob> | i briefly thought that 'start's type would be modified by sibling definitions |
| 2026-03-04 00:32:06 | <yin> | ([a] -> b) -> b ? |
| 2026-03-04 00:32:36 | <chromoblob> | > let start c = c []; push z x c = c (x:z); add (x:y:z) c = c (x+y:z); end z = z in (start :: _) push 1 push 2 push 3 add add end |
| 2026-03-04 00:32:37 | <lambdabot> | [6] |
| 2026-03-04 00:32:40 | <chromoblob> | hmmm |
| 2026-03-04 00:32:44 | <int-e> | yin: that's the easy part... but what's the type it's used at in the final expression? |
| 2026-03-04 00:32:45 | <EvanR> | it was "modified" (specialized) for its use in start push 1 push 2 push 3 add add end |
| 2026-03-04 00:33:17 | <chromoblob> | no it's not modification, it's a changed copy... :) |
| 2026-03-04 00:33:36 | <yin> | is this an interesting exercise or will i just explore my patience? |
| 2026-03-04 00:33:40 | <EvanR> | depends if you have monomorphism restriction! |
| 2026-03-04 00:33:50 | × | nschoe quits (~nschoe@82-65-202-30.subs.proxad.net) (Ping timeout: 252 seconds) |
| 2026-03-04 00:33:52 | <chromoblob> | > let start c = c []; push z x c = c (x:z); add (x:y:z) c = c (x+y:z); end z = z in (start :: ()) push 1 push 2 push 3 add add end |
| 2026-03-04 00:33:53 | <lambdabot> | Couldn't match expected type ‘()’ |
| 2026-03-04 00:33:53 | <lambdabot> | with actual type ‘([a0] -> t0) -> t0’ |
| 2026-03-04 00:33:53 | <lambdabot> | Probable cause: ‘start’ is applied to too few arguments |
All times are in UTC.