Newest at the top
| 2026-04-30 11:10:17 +0000 | <hadronized> | and then there’s usage, where you actually mark a function as polymorphic |
| 2026-04-30 11:10:15 +0000 | <lortabac> | there are different solutions to the problem of "generic" programming, but they depend on the exact specs |
| 2026-04-30 11:09:57 +0000 | <hadronized> | there’s the « codegen » aspect, where we could be happy with just macros |
| 2026-04-30 11:09:28 +0000 | <hadronized> | Hare doesn’t have any and requires codegen to be explict, for instance |
| 2026-04-30 11:09:20 +0000 | <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:01 +0000 | <hadronized> | I like to think of generic programming by extending C, basically |
| 2026-04-30 11:08:29 +0000 | <lortabac> | "generic" can mean so many different things, I don't think it's a particularly useful definition |
| 2026-04-30 11:08:26 +0000 | <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:04 +0000 | <hadronized> | I’m trying to list all the possible ways to do « generic code » |
| 2026-04-30 11:07:52 +0000 | <hadronized> | but I think we are already too close to the details |
| 2026-04-30 11:07:35 +0000 | <hadronized> | yes |
| 2026-04-30 11:07:21 +0000 | <lortabac> | does the method have a different implementation for each type? |
| 2026-04-30 11:06:55 +0000 | <hadronized> | which can cause accidental implementations, and thus is not a super good idea |
| 2026-04-30 11:06:45 +0000 | <hadronized> | but that’s mainly just what Go does |
| 2026-04-30 11:06:39 +0000 | <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:05:18 +0000 | <hadronized> | I think it is, yes |
| 2026-04-30 11:04:06 +0000 | <lortabac> | hadronized: is your goal to provide support for ad-hoc polymorphism? |
| 2026-04-30 11:03:45 +0000 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 255 seconds) |
| 2026-04-30 11:03:11 +0000 | <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:02:52 +0000 | <hadronized> | so with that in mind, I realized that trait can implement rank-N types |
| 2026-04-30 11:02:42 +0000 | <hadronized> | trait Rank2 { fn foo<Here>(…) } |
| 2026-04-30 11:02:26 +0000 | <hadronized> | fn foo<T: Rank2>(arg: T) … { arg.foo("hello"); arg.foo(1) } |
| 2026-04-30 11:02:07 +0000 | <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: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 |