Logs: liberachat/#haskell
| 2026-04-25 12:49:10 | <raincomplex> | does anybody have a good article about the relationship (or lack thereof) between type systems and tests |
| 2026-04-25 12:50:00 | → | nattkyrro joins (~serenity@user/nattkyrro) |
| 2026-04-25 12:53:15 | → | merijn joins (~merijn@62.45.136.136) |
| 2026-04-25 12:53:21 | <ski> | each can do things that the other can't |
| 2026-04-25 12:53:31 | <jreicher> | raincomplex: what kind of relationship are you expecting? A type check is a proof, but testing.... isn't |
| 2026-04-25 12:54:57 | <raincomplex> | i'm just looking for a discussion of the differences and overlaps |
| 2026-04-25 12:54:58 | × | puke quits (~puke@user/puke) (Ping timeout: 250 seconds) |
| 2026-04-25 12:55:56 | <ski> | a type system can ensure static properties about every possible future run of an operation |
| 2026-04-25 12:57:42 | <ski> | tests, and contracts checking more generally, can assign blame for individual run-time issues, but generally can't prove the absence |
| 2026-04-25 12:57:45 | <jreicher> | Emphasis on "every". That's what is special about a proof. That "every" is (probably) infinite. |
| 2026-04-25 12:57:54 | × | merijn quits (~merijn@62.45.136.136) (Ping timeout: 248 seconds) |
| 2026-04-25 12:58:02 | <jreicher> | Tests won't get you infinite coverage |
| 2026-04-25 12:59:00 | <ski> | (then there's property testing, that's using randomly generated test cases, according to some coded distribution of inputs, which is quite useful, because it allows you to state testing *properties*, being more general than particular individual test cases) |
| 2026-04-25 12:59:44 | <ski> | higher-order contract checking systems can also correctly assign blame, when you're passing a callback to some library procedure, determining whether the callback was in breach, or the library operation itself |
| 2026-04-25 12:59:57 | <ski> | (or the caller of it, passing invald inputs) |
| 2026-04-25 13:01:21 | <[exa]> | raincomplex: article more like in "blog post" or "academic paper" |
| 2026-04-25 13:01:25 | <jreicher> | raincomplex: My hunch is that the infinite/finite distinction is what you're after. If you want to show that a specific set of inputs result in the right behaviour, testing will give you that. But if you're in the realm of "all possible inputs", and that all is either infinite or unfeasibly large, testing won't, but type checking might. |
| 2026-04-25 13:04:13 | <raincomplex> | i'm thinking about the development pattern of making some changes, and then fixing the errors that arise when compiling/running. in a statically typed language, the type system covers more of this than in a dynamically typed language, where you need tests (manual or automated) to trigger the errors |
| 2026-04-25 13:05:02 | <ski> | raincomplex : looking into property-based testing (like e.g. QuickCheck and similar), and also (preferably higher-order) contract checking (Racket has one), would probably be helpful, as well |
| 2026-04-25 13:05:13 | <jreicher> | In my opinion there's no such thing as a dynamically typed language in this sense. The "program verification" aspect of types disappear as soon as you don't have static type checking. What is meant by "dynamic types" is more like "dynamic dispatch", which is something different |
| 2026-04-25 13:06:01 | <ski> | sometimes it's called "tag checking" |
| 2026-04-25 13:06:14 | <jreicher> | Put another way, there's no point verifying a program by the time it's running. The damage is already going to be done. |
| 2026-04-25 13:06:45 | <[exa]> | raincomplex: re development patterns, there's an interesting dynamics -- with static types you usually get the error quicker and more reliably located. So I somehow like the type-errors more than test-errors just because the interaction loop is usually much faster |
| 2026-04-25 13:07:46 | <jreicher> | I agree with [exa]. In addition to the cost saving of a faster feedback loop for a competent community the type annotations convey semantic information to humans. |
| 2026-04-25 13:08:31 | <jreicher> | Consider how unpleasant it would be figuring out how to call an API (in any language) without knowing the types of things. |
| 2026-04-25 13:08:49 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-04-25 13:12:34 | × | gmg quits (~user@user/gehmehgeh) (Ping timeout: 265 seconds) |
| 2026-04-25 13:13:07 | <raincomplex> | i like both static and dynamic languages, and i think i'm just trying to get my head around what i like about each, and what the tradeoffs actually are |
| 2026-04-25 13:13:30 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-04-25 13:14:07 | <[exa]> | raincomplex: ask what the types can actually do for you, constructively |
| 2026-04-25 13:14:44 | <[exa]> | in haskell it's quite normal to have whole large parts of programs auto-derived just from the type information |
| 2026-04-25 13:15:44 | <[exa]> | (more ideally, from type information that you don't even write because it's inferred from the rest of the program) |
| 2026-04-25 13:16:37 | <raincomplex> | often i feel like tests i write in a dynamic language are implementing a little type system |
| 2026-04-25 13:16:51 | <raincomplex> | i really like the pattern of following the compiler errors |
| 2026-04-25 13:17:27 | <raincomplex> | it makes big changes a lot easier to keep track of |
| 2026-04-25 13:20:08 | <raincomplex> | this article touches on what i'm thinking about, although it's not its main focus https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ |
| 2026-04-25 13:20:35 | <raincomplex> | this is one thing that jumps out "The key idea is that many dynamically typed languages idiomatically reuse simple data structures like hashmaps to represent what in statically-typed languages are often represented by bespoke datatypes (usually defined as classes or structs)." |
| 2026-04-25 13:20:36 | <jreicher> | raincomplex: "dynamic language" is something different again. The terminology is quite confused |
| 2026-04-25 13:20:42 | <raincomplex> | i'm using it loosely |
| 2026-04-25 13:21:45 | <raincomplex> | i think the aspect i'm considering most at this moment is the "eagerness" of the type system |
| 2026-04-25 13:22:09 | <jreicher> | Even "type system" is ambiguous. Do you mean type check? |
| 2026-04-25 13:22:31 | <raincomplex> | will it complain before i even run the program, or does it only complain when the runtime tries to do something that isn't allowed |
| 2026-04-25 13:23:02 | <jreicher> | Compile time is better. It's the ultimate "fail fast". |
| 2026-04-25 13:24:29 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-04-25 13:25:58 | <jreicher> | So if you're prepared to accept that, the real question is, what do you think is unavoidably runtime? |
| 2026-04-25 13:26:38 | <raincomplex> | if there were nothing unavoidably runtime, we wouldn't need to run programs |
| 2026-04-25 13:27:05 | <[exa]> | raincomplex: oh btw, before I forget -- Julia occupies a very veeeeery interesting overlap of both design "directions"; makes an interesting study material |
| 2026-04-25 13:27:43 | <jreicher> | raincomplex: I didn't say there was nothing. It's more about choosing the boundary |
| 2026-04-25 13:27:53 | <raincomplex> | jreicher, right exactly |
| 2026-04-25 13:30:05 | <raincomplex> | [exa], i don't know much about julia but that definitely sounds interesting |
| 2026-04-25 13:31:39 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2026-04-25 13:38:21 | → | Alex_delenda_est joins (~al_test@85.174.181.200) |
| 2026-04-25 13:40:17 | <ski> | you can have run-time checks inform compile-time types |
| 2026-04-25 13:41:30 | <raincomplex> | say more |
| 2026-04-25 13:41:43 | × | r1bilski quits (~r1bilski@user/r1bilski) (Ping timeout: 264 seconds) |
| 2026-04-25 13:42:26 | <ski> | a run-time check, with branching, that in particular branch(es) add additional typing assumptions |
| 2026-04-25 13:42:32 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-04-25 13:42:50 | <raincomplex> | ah right |
| 2026-04-25 13:43:52 | <ski> | e.g. you could have an operation `frob :: ... -> IO (exists a. (Map String a,Tag a)', where `Tag' is defined by `data Tag :: * -> * where IntTag :: Tag Int; DoubleTag :: Tag Double; ListTag :: Tag a -> Tag [a]' |
| 2026-04-25 13:45:40 | <ski> | so, you get back a finite map with values of some unknown/forgotten/opaque/abstract/skolem type `a' (all values have the *same* type `a', for a single invocation of `frob'), but, when you inspect the accompanying value of type `Tag a', pattern-matching on it will inform the compiler about `a' being `Int', or `Double', or lists (possibly nested) of that |
| 2026-04-25 13:46:40 | <ski> | so, you'd have something like `do ...; (dict,tag) <- frob ...; case tag of TagInt -> {- ok, we have a map of `Int's -}; TagDouble -> ...; TagList tag -> ...' |
| 2026-04-25 13:47:33 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2026-04-25 13:47:46 | <ski> | even though the type of `dict' is `Map String a', where `a' is unknown, after the `frob ...' invocation, we can *learn* more information (at run-time) about `a', by matching on `tag :: Tag a', and that knowledge is then statically (at compile-time), available in each corresponding branch |
| 2026-04-25 13:47:56 | <ski> | raincomplex : makes sense ? |
| 2026-04-25 13:48:50 | <raincomplex> | honestly my haskell is not very good, but just what you said about branches makes sense to me (x |
| 2026-04-25 13:49:09 | <ski> | (you could also, similarly, learn that an unknown type, is an instance of this or that type class) |
| 2026-04-25 13:51:42 | <ski> | btw, you can't really do this with the (restricted, non-general) support for existentials, in say Java, or Rust. because they only allow the idiom `exists a. Widget a *> a', associating an interface dict (for `Widget a' here) with a *single* value of type `a' (rather than e.g. a `Map String a', where you know that all `a's here are the same unknown type) |
| 2026-04-25 13:58:05 | × | pavonia quits (~user@user/siracusa) (Quit: Bye!) |
| 2026-04-25 13:58:17 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-04-25 13:58:55 | → | gmg joins (~user@user/gehmehgeh) |
| 2026-04-25 14:02:31 | × | Ram-Z quits (Ram-Z@2a01:7e01::f03c:91ff:fe57:d2df) (Quit: ZNC - http://znc.in) |
| 2026-04-25 14:02:49 | × | misterfish quits (~misterfis@31-161-39-137.biz.kpn.net) (Ping timeout: 248 seconds) |
| 2026-04-25 14:03:22 | → | gehmehgeh joins (~user@user/gehmehgeh) |
| 2026-04-25 14:03:25 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-04-25 14:04:17 | × | gmg quits (~user@user/gehmehgeh) (Ping timeout: 265 seconds) |
| 2026-04-25 14:05:26 | gehmehgeh | is now known as gmg |
| 2026-04-25 14:05:52 | → | Ram-Z joins (Ram-Z@2a01:7e01::f03c:91ff:fe57:d2df) |
| 2026-04-25 14:09:13 | → | weary-traveler joins (~user@user/user363627) |
| 2026-04-25 14:13:10 | → | r1bilski joins (~r1bilski@user/r1bilski) |
| 2026-04-25 14:14:06 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-04-25 14:18:55 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-04-25 14:19:27 | → | misterfish joins (~misterfis@31-161-39-137.biz.kpn.net) |
| 2026-04-25 14:26:49 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-04-25 14:31:31 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-04-25 14:36:16 | → | alhazrod joins (uid662262@id-662262.lymington.irccloud.com) |
| 2026-04-25 14:36:31 | × | alhazrod quits (uid662262@id-662262.lymington.irccloud.com) (Changing host) |
| 2026-04-25 14:36:31 | → | alhazrod joins (uid662262@user/alhazrod) |
| 2026-04-25 14:40:53 | → | haritz joins (~hrtz@140.228.70.141) |
| 2026-04-25 14:40:54 | × | haritz quits (~hrtz@140.228.70.141) (Changing host) |
| 2026-04-25 14:40:54 | → | haritz joins (~hrtz@user/haritz) |
| 2026-04-25 14:42:17 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-04-25 14:47:24 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2026-04-25 14:54:43 | → | arandombit joins (~arandombi@user/arandombit) |
| 2026-04-25 14:56:43 | → | polykernel_ joins (~polykerne@user/polykernel) |
| 2026-04-25 14:58:03 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-04-25 14:59:04 | × | polykernel quits (~polykerne@user/polykernel) (Ping timeout: 245 seconds) |
| 2026-04-25 14:59:04 | polykernel_ | is now known as polykernel |
| 2026-04-25 15:02:56 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2026-04-25 15:03:04 | → | jmcantrell_ joins (~weechat@user/jmcantrell) |
| 2026-04-25 15:06:30 | × | jmcantrell_ quits (~weechat@user/jmcantrell) (Client Quit) |
All times are in UTC.