Logs: liberachat/#haskell
| 2026-04-30 10:44:31 | <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:44:47 | <hadronized> | as soon as I try to add a compile-time form of interface, I hit coherence, overlapping implementations, etc. |
| 2026-04-30 10:45:06 | <__monty__> | Structural subtyping? |
| 2026-04-30 10:45:08 | <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:24 | <hadronized> | I do have a form of subtyping (refinement types), but it’s not structural |
| 2026-04-30 10:46:19 | <hadronized> | the problem can be addressed at runtime, but I would rather find a way at compile-time |
| 2026-04-30 10:46:27 | <hadronized> | (at runtime: just go the vtable way) |
| 2026-04-30 10:46:36 | → | haskellbridge joins (~hackager@96.28.224.214) |
| 2026-04-30 10:46:36 | ChanServ | sets mode +v haskellbridge |
| 2026-04-30 10:48:32 | <hadronized> | there’s structural interfaces, but they can induce bugs, and as such, I won’t go that route |
| 2026-04-30 10:48:44 | <hadronized> | (the Go way, basically) |
| 2026-04-30 10:49:39 | × | dcb quits (~dcb@user/dcb) (Quit: MSN Messenger v1.9.1) |
| 2026-04-30 10:50:17 | × | divlamir quits (~divlamir@user/divlamir) (Read error: Connection reset by peer) |
| 2026-04-30 10:50:35 | → | divlamir joins (~divlamir@user/divlamir) |
| 2026-04-30 10:51:52 | → | leppard joins (~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) |
| 2026-04-30 10:52:57 | → | califax_ joins (~califax@user/califx) |
| 2026-04-30 10:53:48 | × | califax quits (~califax@user/califx) (Remote host closed the connection) |
| 2026-04-30 10:54:11 | califax_ | is now known as califax |
| 2026-04-30 10:54:29 | → | dcb joins (~dcb@user/dcb) |
| 2026-04-30 10:56:10 | <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:56:42 | <hadronized> | https://www.andres-loeh.de/OpenDatatypes.pdf this one? |
| 2026-04-30 10:56:57 | <lortabac> | yes |
| 2026-04-30 10:57:31 | <lortabac> | however since you mentioned duck typing, I guess your focus is more on overloading |
| 2026-04-30 10:57:52 | <hadronized> | I want to solve generic programming, mainly |
| 2026-04-30 10:58:19 | <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:58:29 | <lortabac> | what do you mean by generic programming? |
| 2026-04-30 10:58:35 | <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:59:00 | <hadronized> | forall t: type fn add(a: t, b: t): t = a + b; |
| 2026-04-30 10:59:01 | <hadronized> | this |
| 2026-04-30 10:59:18 | <hadronized> | this is not valid, because + cannot be used with type directly |
| 2026-04-30 10:59:29 | <hadronized> | so I’m looking for all the alternatives to allow for it |
| 2026-04-30 10:59:33 | <hadronized> | Zig, for instance, does allow that code |
| 2026-04-30 10:59:38 | <hadronized> | but it will fail at instantiation |
| 2026-04-30 10:59:48 | <hadronized> | Rust requires where T: Add |
| 2026-04-30 10:59:54 | <hadronized> | (similar to Haskell’s typeclasses) |
| 2026-04-30 11:00:26 | <hadronized> | C++ concepts are a bit similar to compile-time only typeclasses / traits, but without coherence |
| 2026-04-30 11:00:44 | <hadronized> | so you can have overlapping instances and specialization, even though I never remember the rules |
| 2026-04-30 11:00:48 | <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:01:12 | → | craunts795335385 joins (~craunts@152.32.100.66) |
| 2026-04-30 11:01:19 | × | tromp quits (~textual@2001:1c00:340e:2700:908b:73d:c800:c6b4) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-04-30 11:02:07 | <hadronized> | there’s something interesting about Rust <=> Haskell: Haskell has rank-2 types, which allow you to use forall to introduce a new rank. Rust doesn’t, and to solve that problem, you need to introduce a trait with a generic method |
| 2026-04-30 11:02:26 | <hadronized> | fn foo<T: Rank2>(arg: T) … { arg.foo("hello"); arg.foo(1) } |
| 2026-04-30 11:02:42 | <hadronized> | trait Rank2 { fn foo<Here>(…) } |
| 2026-04-30 11:02:52 | <hadronized> | so with that in mind, I realized that trait can implement rank-N types |
| 2026-04-30 11:03:11 | <hadronized> | so I’m wondering whether, regarding generic functions and contracts, whether they implement a more generalized way to express what I want here |
| 2026-04-30 11:03:45 | × | misterfish quits (~misterfis@84.53.85.146) (Ping timeout: 255 seconds) |
| 2026-04-30 11:04:06 | <lortabac> | hadronized: is your goal to provide support for ad-hoc polymorphism? |
| 2026-04-30 11:05:18 | <hadronized> | I think it is, yes |
| 2026-04-30 11:06:39 | <hadronized> | for the add example, I guess instead of having to create typeclasses / traits, we could have something like where op"+"(t, t): t |
| 2026-04-30 11:06:45 | <hadronized> | but that’s mainly just what Go does |
| 2026-04-30 11:06:55 | <hadronized> | which can cause accidental implementations, and thus is not a super good idea |
| 2026-04-30 11:07:21 | <lortabac> | does the method have a different implementation for each type? |
| 2026-04-30 11:07:35 | <hadronized> | yes |
| 2026-04-30 11:07:52 | <hadronized> | but I think we are already too close to the details |
| 2026-04-30 11:08:04 | <hadronized> | I’m trying to list all the possible ways to do « generic code » |
| 2026-04-30 11:08:26 | <hadronized> | Zig is interesting with its reflection, but I know I won’t go that route because it’d mean a nightmare for people consuming those functions |
| 2026-04-30 11:08:29 | <lortabac> | "generic" can mean so many different things, I don't think it's a particularly useful definition |
| 2026-04-30 11:09:01 | <hadronized> | I like to think of generic programming by extending C, basically |
| 2026-04-30 11:09:20 | <hadronized> | generic programming is just how you generate code at compile-time for different types / values known at compile-time |
| 2026-04-30 11:09:28 | <hadronized> | Hare doesn’t have any and requires codegen to be explict, for instance |
| 2026-04-30 11:09:57 | <hadronized> | there’s the « codegen » aspect, where we could be happy with just macros |
| 2026-04-30 11:10:15 | <lortabac> | there are different solutions to the problem of "generic" programming, but they depend on the exact specs |
| 2026-04-30 11:10:17 | <hadronized> | and then there’s usage, where you actually mark a function as polymorphic |
| 2026-04-30 11:10:39 | <lortabac> | unless you specify the details, it's impossible to find an answer to your question |
| 2026-04-30 11:11:38 | <lortabac> | should generic functions be extensible, like type classes? |
| 2026-04-30 11:12:17 | <lortabac> | or would you e.g. have all the instances of "+" in the same place? |
| 2026-04-30 11:15:30 | <lortabac> | other question: is it important that the implementation is chosen statically? Or would a solution based on rank-n types + implicit parameters fit your specs too? |
| 2026-04-30 11:16:16 | <hadronized> | I am not sure to understand your last point with implicit parameters |
| 2026-04-30 11:16:17 | <lortabac> | (this means no global coherence) |
| 2026-04-30 11:16:32 | → | r1bilski joins (~r1bilski@user/r1bilski) |
| 2026-04-30 11:16:59 | → | misterfish joins (~misterfis@84.53.85.146) |
| 2026-04-30 11:17:51 | <lortabac> | I'm not sure, but I think Scala does something like this |
| 2026-04-30 11:17:52 | × | Pozyomka quits (~pyon@user/pyon) (Quit: fuck logind) |
| 2026-04-30 11:18:12 | <lortabac> | I don't know, I'm just listing various alternatives to type classes :) |
| 2026-04-30 11:18:13 | → | tremon joins (~tremon@83.80.159.219) |
| 2026-04-30 11:20:35 | → | xff0x joins (~xff0x@ah206235.dynamic.ppp.asahi-net.or.jp) |
| 2026-04-30 11:28:42 | × | misterfish quits (~misterfis@84.53.85.146) (Ping timeout: 246 seconds) |
| 2026-04-30 11:29:40 | × | r1bilski quits (~r1bilski@user/r1bilski) (Ping timeout: 265 seconds) |
| 2026-04-30 11:31:41 | × | dcb quits (~dcb@user/dcb) (Quit: MSN Messenger v1.9.1) |
| 2026-04-30 11:35:59 | × | kimiamania40 quits (~67ff9c51@user/kimiamania) (Quit: PegeLinux) |
| 2026-04-30 11:36:10 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-04-30 11:37:14 | → | kimiamania40 joins (~67ff9c51@user/kimiamania) |
| 2026-04-30 11:40:44 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-04-30 11:43:42 | → | Googulator56 joins (~Googulato@84-236-65-50.pool.digikabel.hu) |
| 2026-04-30 11:44:16 | × | phm quits (~peter@fsf/member/phm) (Quit: leaving) |
| 2026-04-30 11:44:55 | → | phm joins (~peter@fsf/member/phm) |
| 2026-04-30 11:46:38 | → | DetourNe- joins (~DetourNet@user/DetourNetworkUK) |
| 2026-04-30 11:47:00 | × | DetourNetworkUK quits (~DetourNet@user/DetourNetworkUK) (Read error: Connection reset by peer) |
| 2026-04-30 11:47:05 | → | misterfish joins (~misterfis@84.53.85.146) |
| 2026-04-30 11:47:17 | × | Googulator quits (~Googulato@78-131-16-66.pool.digikabel.hu) (Ping timeout: 245 seconds) |
| 2026-04-30 11:47:20 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 2026-04-30 11:48:57 | DetourNe- | is now known as DetourNetworkUK |
| 2026-04-30 11:53:14 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-04-30 11:54:24 | Googulator56 | is now known as Googulator |
| 2026-04-30 11:58:17 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2026-04-30 11:58:49 | → | Pozyomka joins (~pyon@user/pyon) |
| 2026-04-30 12:05:53 | → | nunggu joins (~q@user/nunggu) |
| 2026-04-30 12:06:30 | → | r1bilski joins (~r1bilski@user-31-175-22-58.play-internet.pl) |
| 2026-04-30 12:06:30 | × | r1bilski quits (~r1bilski@user-31-175-22-58.play-internet.pl) (Changing host) |
| 2026-04-30 12:06:30 | → | r1bilski joins (~r1bilski@user/r1bilski) |
All times are in UTC.