Newest at the top
| 2026-04-30 11:18:13 +0000 | tremon | (~tremon@83.80.159.219) tremon |
| 2026-04-30 11:18:12 +0000 | <lortabac> | I don't know, I'm just listing various alternatives to type classes :) |
| 2026-04-30 11:17:52 +0000 | Pozyomka | (~pyon@user/pyon) (Quit: fuck logind) |
| 2026-04-30 11:17:51 +0000 | <lortabac> | I'm not sure, but I think Scala does something like this |
| 2026-04-30 11:16:59 +0000 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2026-04-30 11:16:32 +0000 | r1bilski | (~r1bilski@user/r1bilski) r1bilski |
| 2026-04-30 11:16:17 +0000 | <lortabac> | (this means no global coherence) |
| 2026-04-30 11:16:16 +0000 | <hadronized> | I am not sure to understand your last point with implicit parameters |
| 2026-04-30 11:15:30 +0000 | <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:12:17 +0000 | <lortabac> | or would you e.g. have all the instances of "+" in the same place? |
| 2026-04-30 11:11:38 +0000 | <lortabac> | should generic functions be extensible, like type classes? |
| 2026-04-30 11:10:39 +0000 | <lortabac> | unless you specify the details, it's impossible to find an answer to your question |
| 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? |