Newest at the top
| 2024-11-19 13:21:34 +0100 | <dminuoso> | kuribas: Structural subtyping captures some, but not all commonly mentioned, ideas of duck typing. |
| 2024-11-19 13:20:41 +0100 | <dminuoso> | It mostly arises from the idea of smalltalk object orientation, where if some object behaves as if it was a duck, you can just call it a duck. |
| 2024-11-19 13:20:17 +0100 | <kuribas> | looks like structural subtyping to me: https://peps.python.org/pep-0544/ |
| 2024-11-19 13:20:04 +0100 | <dminuoso> | Well, the "if it doesn't" is not something that duck type proponents really worry about. |
| 2024-11-19 13:19:47 +0100 | <dminuoso> | Duck typing is nothing that you can sensibly annotate with formal names, because its a very loose abstract idea. |
| 2024-11-19 13:19:40 +0100 | <kuribas> | "if it works out". If it doesn't, you get an unpredictable error. |
| 2024-11-19 13:19:10 +0100 | <dminuoso> | In duck typing, rather than formally (via a type system) asserting that you have some sort of impedance match between componets (say the function signature with the passed arguments), if it works out at runtime, thats just as good. |
| 2024-11-19 13:19:06 +0100 | <kuribas> | For example anonymous records. |
| 2024-11-19 13:19:04 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2024-11-19 13:18:44 +0100 | Digit | (~user@user/digit) (Ping timeout: 260 seconds) |
| 2024-11-19 13:18:42 +0100 | <kuribas> | Well, if duck typing is structural typing, then idris doesn't have it, but it's possible to emulate it with dependent types. |
| 2024-11-19 13:18:26 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) stiell |
| 2024-11-19 13:17:25 +0100 | <dminuoso> | Id say not really. |
| 2024-11-19 13:16:15 +0100 | <kuribas> | Isn't duck typing the equivalent of type classes? |
| 2024-11-19 13:15:48 +0100 | <dminuoso> | If it type checks like a duck, we shall make it a duck. |
| 2024-11-19 13:15:34 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) |
| 2024-11-19 13:15:28 +0100 | <dminuoso> | Sounds like the type system way of duck typing. :-) |
| 2024-11-19 13:15:16 +0100 | euleritian | (~euleritia@dynamic-176-001-000-183.176.1.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-11-19 13:15:06 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2024-11-19 13:14:59 +0100 | <kuribas> | Literally. They merged the auto implicit feature and type classes. |
| 2024-11-19 13:14:46 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2024-11-19 13:14:30 +0100 | <kuribas> | instance resolution corresponds to proof search. |
| 2024-11-19 13:14:20 +0100 | <kuribas> | Leary: no, that's just type checking, implicit resolution and proof search are different features. |
| 2024-11-19 13:12:56 +0100 | <Leary> | Sounds evil. Isn't that just IncoherentInstances? |
| 2024-11-19 13:11:57 +0100 | <kuribas> | geekosaur: rebindable syntax will use the (>>=) in scope, but in idris it will try every definition of (>>=), and pick the one that typechecks.. |
| 2024-11-19 13:10:52 +0100 | <kuribas> | geekosaur: It's not the same. In haskell you must have a non ambiguous way to resolve (>>=), but in idris it's overloaded, it will do a search. |
| 2024-11-19 13:09:03 +0100 | ubert | (~Thunderbi@178.115.41.15.wireless.dyn.drei.com) (Ping timeout: 252 seconds) |
| 2024-11-19 13:08:08 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) chiselfuse |
| 2024-11-19 13:07:46 +0100 | mari-estel | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2024-11-19 13:07:40 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2024-11-19 13:05:58 +0100 | <hellwolf> | "The sum of a collection of actions using (<|>), generalizing concat." |
| 2024-11-19 13:05:41 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds) |
| 2024-11-19 13:05:41 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Ping timeout: 260 seconds) |
| 2024-11-19 13:05:40 +0100 | <hellwolf> | I can't wrap my head around intuitively wrt asum. fmap Just. I can see the type matches. |
| 2024-11-19 13:03:31 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) (Remote host closed the connection) |
| 2024-11-19 13:03:22 +0100 | sroso | (~sroso@user/SrOso) (Quit: Leaving :)) |
| 2024-11-19 13:02:01 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-11-19 13:01:33 +0100 | <dminuoso> | (Or maybe its defined in some module in your project) |
| 2024-11-19 13:01:09 +0100 | <dminuoso> | As you can see, it's from other packages. I think hoogle always lists `base` references first. |
| 2024-11-19 13:00:23 +0100 | <dminuoso> | hellwolf: You can use hoogle https://hoogle.haskell.org/?hoogle=nothing to discover likely origins of identifiers. |
| 2024-11-19 13:00:09 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-11-19 13:00:04 +0100 | son0p | (~ff@2800:e2:f80:ee7::4) (Ping timeout: 260 seconds) |
| 2024-11-19 12:59:54 +0100 | <hellwolf> | same for nothing <-- where is it even from? I used Const nothing |
| 2024-11-19 12:59:33 +0100 | <hellwolf> | yes, that's interest. but I had to import Data.Applicative |
| 2024-11-19 12:57:47 +0100 | <dminuoso> | No worries. Leary's answer is more clever, though if you are curious. |
| 2024-11-19 12:56:43 +0100 | <hellwolf> | but "either" is good. here shows my lack of production experience of Haskell, in general. I only plays around :) |
| 2024-11-19 12:56:10 +0100 | <hellwolf> | yea, got it, it would stay Either |
| 2024-11-19 12:55:14 +0100 | <dminuoso> | Note that it's the same `m` here in both arguments and the resultg? |
| 2024-11-19 12:55:03 +0100 | <lambdabot> | Monad m => m a -> (a -> m b) -> m b |
| 2024-11-19 12:55:02 +0100 | <dminuoso> | :t (>>=) |