Newest at the top
| 2026-04-30 11:01:19 +0000 | tromp | (~textual@2001:1c00:340e:2700:908b:73d:c800:c6b4) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-04-30 11:01:12 +0000 | craunts795335385 | (~craunts@152.32.100.66) |
| 2026-04-30 11:00:48 +0000 | <yin> | rubberduck typing: when looking at a function to see what it does makes you immediately realize what's wrong with it |
| 2026-04-30 11:00:44 +0000 | <hadronized> | so you can have overlapping instances and specialization, even though I never remember the rules |
| 2026-04-30 11:00:26 +0000 | <hadronized> | C++ concepts are a bit similar to compile-time only typeclasses / traits, but without coherence |
| 2026-04-30 10:59:54 +0000 | <hadronized> | (similar to Haskell’s typeclasses) |
| 2026-04-30 10:59:48 +0000 | <hadronized> | Rust requires where T: Add |
| 2026-04-30 10:59:38 +0000 | <hadronized> | but it will fail at instantiation |
| 2026-04-30 10:59:33 +0000 | <hadronized> | Zig, for instance, does allow that code |
| 2026-04-30 10:59:29 +0000 | <hadronized> | so I’m looking for all the alternatives to allow for it |
| 2026-04-30 10:59:18 +0000 | <hadronized> | this is not valid, because + cannot be used with type directly |
| 2026-04-30 10:59:01 +0000 | <hadronized> | this |
| 2026-04-30 10:59:00 +0000 | <hadronized> | forall t: type fn add(a: t, b: t): t = a + b; |
| 2026-04-30 10:58:35 +0000 | <hadronized> | and you do pretty much anything you want in the function, it’s not driven by an external contract, which is bad to me |
| 2026-04-30 10:58:29 +0000 | <lortabac> | what do you mean by generic programming? |
| 2026-04-30 10:58:19 +0000 | <hadronized> | duck typing is bad in the sense that you need to look at the function to know what you are supposed to call it with |
| 2026-04-30 10:57:52 +0000 | <hadronized> | I want to solve generic programming, mainly |
| 2026-04-30 10:57:31 +0000 | <lortabac> | however since you mentioned duck typing, I guess your focus is more on overloading |
| 2026-04-30 10:56:57 +0000 | <lortabac> | yes |
| 2026-04-30 10:56:42 +0000 | <hadronized> | https://www.andres-loeh.de/OpenDatatypes.pdf this one? |
| 2026-04-30 10:56:10 +0000 | <lortabac> | hadronized: for the expression problem, a lightweight alternative would be open data-types and functions (see the paper by Andres Löh) |
| 2026-04-30 10:54:29 +0000 | dcb | (~dcb@user/dcb) dcb |
| 2026-04-30 10:54:11 +0000 | califax_ | califax |
| 2026-04-30 10:53:48 +0000 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2026-04-30 10:52:57 +0000 | califax_ | (~califax@user/califx) califx |
| 2026-04-30 10:51:52 +0000 | leppard | (~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) Inline |
| 2026-04-30 10:50:35 +0000 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2026-04-30 10:50:17 +0000 | divlamir | (~divlamir@user/divlamir) (Read error: Connection reset by peer) |
| 2026-04-30 10:49:39 +0000 | dcb | (~dcb@user/dcb) (Quit: MSN Messenger v1.9.1) |
| 2026-04-30 10:48:44 +0000 | <hadronized> | (the Go way, basically) |
| 2026-04-30 10:48:32 +0000 | <hadronized> | there’s structural interfaces, but they can induce bugs, and as such, I won’t go that route |
| 2026-04-30 10:46:36 +0000 | ChanServ | +v haskellbridge |
| 2026-04-30 10:46:36 +0000 | haskellbridge | (~hackager@96.28.224.214) hackager |
| 2026-04-30 10:46:27 +0000 | <hadronized> | (at runtime: just go the vtable way) |
| 2026-04-30 10:46:19 +0000 | <hadronized> | the problem can be addressed at runtime, but I would rather find a way at compile-time |
| 2026-04-30 10:45:24 +0000 | <hadronized> | I do have a form of subtyping (refinement types), but it’s not structural |
| 2026-04-30 10:45:08 +0000 | <hadronized> | if you remove generic code, you entirely remove that class of problem, but you also remove a lot of useful features that my language needs to have |
| 2026-04-30 10:45:06 +0000 | <__monty__> | Structural subtyping? |
| 2026-04-30 10:44:47 +0000 | <hadronized> | as soon as I try to add a compile-time form of interface, I hit coherence, overlapping implementations, etc. |
| 2026-04-30 10:44:31 +0000 | <hadronized> | the duck typing approach is something I deeply disdain, but it does have the advantage of not introducing a ton of complexity in the language, and the tradeoff is that you have a lot of cognitive complexity at use site |
| 2026-04-30 10:43:43 +0000 | <hadronized> | yes, hence why I’m wondering |
| 2026-04-30 10:43:30 +0000 | <__monty__> | Typeclasses address an expressivity problem. Not sure what correctness problem exists that they could/would address. |
| 2026-04-30 10:42:15 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-04-30 10:42:12 +0000 | <hadronized> | (that’s the why of my initial question regarding typeclasses and whether they solve a correctness problem) |
| 2026-04-30 10:41:55 +0000 | <hadronized> | the main goal of my language is correctness |
| 2026-04-30 10:41:50 +0000 | <hadronized> | so I am looking for a lighter alternative, even if I lose a bit of expressiveness |
| 2026-04-30 10:41:32 +0000 | <hadronized> | or requires synchronizing the documentation with the content of the body, which has been proven numerous times a bad idea (and even Zig std doesn’t do it correctly) |
| 2026-04-30 10:41:03 +0000 | <hadronized> | it forces you to look at the body to know the exact way of using that function |
| 2026-04-30 10:41:02 +0000 | haskellbridge | (~hackager@96.28.224.214) (Read error: Connection reset by peer) |
| 2026-04-30 10:40:48 +0000 | <hadronized> | because looking at something like fn whatdoesitdo(comptime T: type, a: T, b: T) T { return a + b; } |