| 2022-10-05 00:02:17 +0200 | mikoto-chan | (~mikoto-ch@164.5.249.78) (Ping timeout: 268 seconds) |
| 2022-10-05 00:02:47 +0200 | goig | (~goig@202.91.42.7) |
| 2022-10-05 00:02:53 +0200 | <goig> | What are the morphisms of the category of endofunctors? |
| 2022-10-05 00:03:08 +0200 | <goig> | How do we call a monoid in the category of sets? |
| 2022-10-05 00:06:41 +0200 | <dminuoso> | goig: morphisms in that category are just natural transformations |
| 2022-10-05 00:07:05 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-10-05 00:07:59 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-10-05 00:08:47 +0200 | <dminuoso> | Take note that the term `monoid` is just typical mathematical compact imprecision, that joke really reads as `a monad is a monoid in the monoidal category of endofunctors, equipped with a particular tensor. |
| 2022-10-05 00:09:05 +0200 | <dminuoso> | And a `monoid` in a `monoidal category` is a special construction with respect to that tensor |
| 2022-10-05 00:10:04 +0200 | <dminuoso> | The tensor in question for the joke is Endofunctor Componsition, represented as (:.:) |
| 2022-10-05 00:10:14 +0200 | mastarija | (~mastarija@2a05:4f46:e03:6000:f63b:c026:eeb8:e131) (Ping timeout: 268 seconds) |
| 2022-10-05 00:10:59 +0200 | <dminuoso> | It may be of interest, that other monoidal categories exist too. For example Applicative is the monoid of the monoidal category of Endofunctors, equipped with Day as its tensor. |
| 2022-10-05 00:11:15 +0200 | <dminuoso> | *An applicative is a monoid in the monoidal category... |
| 2022-10-05 00:12:04 +0200 | <goig> | The category of endofunctors should be monoidal if I understand it right |
| 2022-10-05 00:12:07 +0200 | <goig> | Day? |
| 2022-10-05 00:12:14 +0200 | ski | . o O ( <https://baldursgate.fandom.com/wiki/Tenser's_Transformation> ) |
| 2022-10-05 00:12:22 +0200 | <ski> | Day convolution |
| 2022-10-05 00:12:40 +0200 | <dminuoso> | data Day f g a = forall b c. Day (f b) (g c) (b -> c -> a) |
| 2022-10-05 00:13:27 +0200 | <ski> | <https://hackage.haskell.org/package/kan-extensions-5.2.5/docs/Data-Functor-Day.html> |
| 2022-10-05 00:13:52 +0200 | mmhat | (~mmh@p200300f1c71ac6cfee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.6) |
| 2022-10-05 00:14:44 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 265 seconds) |
| 2022-10-05 00:14:47 +0200 | <geekosaur> | "tenser", said the tensor… |
| 2022-10-05 00:14:49 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-05 00:15:34 +0200 | <dminuoso> | goig: Also being monoidal is not an intrinsic property of a category, just like being a semigroup is not an intrinsic property of an integer |
| 2022-10-05 00:15:51 +0200 | zeenk | (~zeenk@2a02:2f04:a20a:3e00:5712:52b0:ca1d:bc63) (Quit: Konversation terminated!) |
| 2022-10-05 00:16:12 +0200 | <monochrom> | I thought you would prefer functor composition so that you can envision join :: M∘M -> M as a binary operator. |
| 2022-10-05 00:16:16 +0200 | <dminuoso> | A monoidal Category is just any 3-tuple (C, ⊗, I) satisfying a bunch of laws. |
| 2022-10-05 00:16:43 +0200 | <dminuoso> | (And there may be multiple 3-tuples involving the same C) |
| 2022-10-05 00:18:00 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.) |
| 2022-10-05 00:19:00 +0200 | caryhartline | (~caryhartl@2600:1700:2d0:8d30:c9ff:16c0:a456:ab01) (Quit: caryhartline) |
| 2022-10-05 00:19:03 +0200 | <goig> | A monad then is a 3-tuple where the C is a category of endofunctors |
| 2022-10-05 00:19:40 +0200 | <dminuoso> | So (Hask, (:.:), Identity) is such an a monoidal category, it is the particular choice for the joke |
| 2022-10-05 00:20:21 +0200 | <dminuoso> | Where (:.:) is just endofunctor composition, so: (Maybe :.: IO) a ~~~ Maybe (IO a) |
| 2022-10-05 00:20:40 +0200 | <dminuoso> | ~~~ denoting equality up to isomorphism |
| 2022-10-05 00:20:47 +0200 | Guest41 | (~Guest41@181.229.251.140) |
| 2022-10-05 00:20:48 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::778c) (Ping timeout: 264 seconds) |
| 2022-10-05 00:20:58 +0200 | <goig> | Hmm, (:.:)? |
| 2022-10-05 00:20:59 +0200 | <monochrom> | OK I'm happy now. :) |
| 2022-10-05 00:21:09 +0200 | <goig> | oh |
| 2022-10-05 00:21:21 +0200 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 250 seconds) |
| 2022-10-05 00:21:22 +0200 | <dminuoso> | It's just an operator style newtype constructor |
| 2022-10-05 00:21:25 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-05 00:22:04 +0200 | <dminuoso> | > newtype (:.:) f g p = Comp { unComp :: f (g p) } |
| 2022-10-05 00:22:06 +0200 | <lambdabot> | <hint>:1:1: error: parse error on input ‘newtype’ |
| 2022-10-05 00:22:07 +0200 | <dminuoso> | @let newtype (:.:) f g p = Comp { unComp :: f (g p) } |
| 2022-10-05 00:22:08 +0200 | <lambdabot> | Defined. |
| 2022-10-05 00:23:15 +0200 | <dminuoso> | goig: Its really the same as function composition, except at the type level (except it works only up to isomorphism, `Maybe (IO a)` is not the actual same type as `(Maybe :.: IO) a` |
| 2022-10-05 00:23:23 +0200 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-10-05 00:23:26 +0200 | <dminuoso> | At any rate |
| 2022-10-05 00:24:05 +0200 | <goig> | "Frankly I don't think category theory is particularly useful. It is do abstracted that it can describe everything, but at the same time conclude nothing" What's your take on their statement? |
| 2022-10-05 00:24:28 +0200 | Guest41 | (~Guest41@181.229.251.140) (Client Quit) |
| 2022-10-05 00:25:48 +0200 | <hpc> | i constantly find myself wishing for Monad in other languages to make some specific thing or another easier to write |
| 2022-10-05 00:26:19 +0200 | <dminuoso> | goig: So just a short glimpse, without going the painful details of the construction, demonstrating the laws, and so on: |
| 2022-10-05 00:26:38 +0200 | <dminuoso> | a monoid in the monoidal category of (C, (:.:), Identity) is equipped with two natural transformations: |
| 2022-10-05 00:26:49 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-05 00:26:56 +0200 | <dminuoso> | μ: M ⊗ M → M |
| 2022-10-05 00:27:10 +0200 | <dminuoso> | μ: M :.: M → M |
| 2022-10-05 00:27:21 +0200 | <dminuoso> | η : Identity -> M |
| 2022-10-05 00:27:32 +0200 | <dminuoso> | Since these are natural transformations, we can reprsent them in Haskell too |
| 2022-10-05 00:28:05 +0200 | <qrpnxz> | idk about category theory, but are not the type classes in haskell undoubtedly useful? |
| 2022-10-05 00:28:12 +0200 | <dminuoso> | % type (~>) f g = forall a. f a -> f a |
| 2022-10-05 00:28:13 +0200 | <yahb2> | <interactive>:224:6: error: ; Illegal declaration of a type or class operator ‘~>’ ; Use TypeOperators to declare operators in type and declarations |
| 2022-10-05 00:28:18 +0200 | <dminuoso> | % :set -XTypeOperators |
| 2022-10-05 00:28:19 +0200 | <yahb2> | <interactive>:1:1: error: Not in scope: ‘Yahb2Defs.limitedPrint’ |
| 2022-10-05 00:28:25 +0200 | <dminuoso> | @let type (~>) f g = forall a. f a -> f a |
| 2022-10-05 00:28:26 +0200 | <lambdabot> | Defined. |
| 2022-10-05 00:28:28 +0200 | <dminuoso> | Here. |
| 2022-10-05 00:28:34 +0200 | <dminuoso> | So in haskell terms we can now say: |
| 2022-10-05 00:28:47 +0200 | <dminuoso> | μ :: M :.: M ~> M |
| 2022-10-05 00:28:53 +0200 | <dminuoso> | η : Identity ~> M |
| 2022-10-05 00:29:06 +0200 | <dminuoso> | And it turns out, these are exactly the two methods of monad |
| 2022-10-05 00:29:11 +0200 | <dminuoso> | > :t join |
| 2022-10-05 00:29:12 +0200 | <lambdabot> | <hint>:1:1: error: parse error on input ‘:’ |
| 2022-10-05 00:29:13 +0200 | <dminuoso> | :t join |
| 2022-10-05 00:29:14 +0200 | <lambdabot> | Monad m => m (m a) -> m a |
| 2022-10-05 00:29:33 +0200 | <goig> | `η : Identity -> M` Isn't identity an object? |
| 2022-10-05 00:29:44 +0200 | <dminuoso> | Hold on, its a natural transformation |
| 2022-10-05 00:29:49 +0200 | <dminuoso> | Observe that m (m a) ~~~ (m :.: m) a |
| 2022-10-05 00:29:52 +0200 | <ski> | in this instance, `Identity' is a functor |
| 2022-10-05 00:30:07 +0200 | <ski> | (which is an object, in the category of endofunctors) |
| 2022-10-05 00:30:13 +0200 | <dminuoso> | goig: In haskell lingo you would write: `forall a. Identity a -> M a` |
| 2022-10-05 00:30:20 +0200 | <dminuoso> | or given the above type synonym: Identity ~> M |
| 2022-10-05 00:30:31 +0200 | ski | idly wonders how much Haskell goig is familiar with |
| 2022-10-05 00:30:47 +0200 | <dminuoso> | :t join |
| 2022-10-05 00:30:48 +0200 | <lambdabot> | Monad m => m (m a) -> m a |
| 2022-10-05 00:30:54 +0200 | <dminuoso> | Observe that m (m a) ~~~ (m :.: m) a |
| 2022-10-05 00:31:00 +0200 | <dminuoso> | So we could thionk of join having the type signature: |
| 2022-10-05 00:31:08 +0200 | <dminuoso> | join :: (m :.: m) ~> m |
| 2022-10-05 00:31:14 +0200 | <dminuoso> | and similarly for `return` |
| 2022-10-05 00:31:16 +0200 | <dminuoso> | :t return |
| 2022-10-05 00:31:17 +0200 | <lambdabot> | Monad m => a -> m a |
| 2022-10-05 00:31:23 +0200 | <dminuoso> | Identity a ~~~ a |
| 2022-10-05 00:31:39 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 265 seconds) |
| 2022-10-05 00:31:39 +0200 | <dminuoso> | So we can also write this as `Identity ~> m` |
| 2022-10-05 00:31:53 +0200 | <goig> | Iirc η is return in haskell |
| 2022-10-05 00:32:00 +0200 | <dminuoso> | Yes exactly |
| 2022-10-05 00:32:06 +0200 | <dminuoso> | And μ is just join |
| 2022-10-05 00:32:27 +0200 | <monochrom> | Yes join is a natural transformation. |
| 2022-10-05 00:32:37 +0200 | <goig> | Wait join? |
| 2022-10-05 00:32:43 +0200 | <dminuoso> | :t join |
| 2022-10-05 00:32:44 +0200 | <lambdabot> | Monad m => m (m a) -> m a |
| 2022-10-05 00:33:03 +0200 | <goig> | So :.: is >>= |
| 2022-10-05 00:33:07 +0200 | <dminuoso> | No |
| 2022-10-05 00:33:18 +0200 | <dminuoso> | `join` and `>>=` have the same power |
| 2022-10-05 00:33:38 +0200 | <dminuoso> | We could, in principle, define any Monad instance just in terms of `join` instead of (>>=) |
| 2022-10-05 00:33:51 +0200 | <monochrom> | So in a category of endofunctors using natural transformations for morphisms, you get to write "M :.: M -> M", the -> there is "generically a morphism in my category, oh but this means a natural transformation in my case". |
| 2022-10-05 00:34:25 +0200 | <dminuoso> | The reason you cant, and why join isnt even a method of typeclass is actually just a kind of accident and has to do with unrelated extensions. |
| 2022-10-05 00:34:31 +0200 | <dminuoso> | *of the typeclass Monad |
| 2022-10-05 00:35:12 +0200 | <dminuoso> | `join` used to be a method, but it had to be removed for reasons irrelevant to this discussion |
| 2022-10-05 00:35:26 +0200 | <goig> | I am still a bit confused about return tho. Identity is a particular object right? |
| 2022-10-05 00:35:35 +0200 | <dminuoso> | newtype Identity a = Identith a |
| 2022-10-05 00:35:37 +0200 | <dminuoso> | newtype Identity a = Identity a |
| 2022-10-05 00:35:41 +0200 | <dminuoso> | That's Identity . |
| 2022-10-05 00:35:47 +0200 | <ski> | goig : object of what ? |
| 2022-10-05 00:35:50 +0200 | <dminuoso> | It's is an endofunctor |
| 2022-10-05 00:35:55 +0200 | <monochrom> | I have doubts about that. join was not a method around 2000 when I was learning Haskell, and said extension didn't exist. |
| 2022-10-05 00:36:03 +0200 | <goig> | And M is a category. But there's only one identity object no? |
| 2022-10-05 00:36:52 +0200 | <ski> | `M' above is a monad |
| 2022-10-05 00:37:02 +0200 | <ski> | (not a category) |
| 2022-10-05 00:37:09 +0200 | <goig> | Newtype? |
| 2022-10-05 00:37:13 +0200 | <dminuoso> | goig: There is two different things we associate with the word "identity" here. |
| 2022-10-05 00:37:23 +0200 | <dminuoso> | goig: there is an identity with respect to the tensor (:.:) |
| 2022-10-05 00:37:27 +0200 | <monochrom> | M is an endofunctor. Identity is also an endofunctor. Both are objects in this context. |
| 2022-10-05 00:37:41 +0200 | <dminuoso> | that is, an identity on the *monoidal category* construction (which is Identity, with respect to (:.:)) |
| 2022-10-05 00:37:55 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 258 seconds) |
| 2022-10-05 00:38:23 +0200 | <dminuoso> | and there is an identity on the *monoid of the monoidal cagetory (of endofunctors)*, which happens to be a morphism (which in this case is a natural transformation) |
| 2022-10-05 00:40:02 +0200 | <goig> | Wait. So a monoid is an object in a monoidal category |
| 2022-10-05 00:40:13 +0200 | <monochrom> | No. |
| 2022-10-05 00:40:26 +0200 | <goig> | (Aka an object of C in (C,\otimes,I)) |
| 2022-10-05 00:40:49 +0200 | <dminuoso> | goig: "a monoid in a monoidal category" is a particular construction. Do not conflate this usage of the word "monoid" with any generic "monoid" |
| 2022-10-05 00:41:24 +0200 | <ski> | a monoid is an object in a monoidal category, *together* with two particular morphisms, satisfying three laws |
| 2022-10-05 00:41:29 +0200 | donato | (uid570353@id-570353.ilkley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-10-05 00:41:30 +0200 | <dminuoso> | given a monoidal category, *some* objects *may* be monoids. |
| 2022-10-05 00:41:40 +0200 | <dminuoso> | (that is, some objects may be "monoids in that monoidal category") |
| 2022-10-05 00:41:48 +0200 | mncheck | (~mncheck@193.224.205.254) (Ping timeout: 265 seconds) |
| 2022-10-05 00:41:51 +0200 | <goig> | Ya a monoid in a monoidal category. Not that semigroup or whatever else |
| 2022-10-05 00:41:57 +0200 | <dminuoso> | Right |
| 2022-10-05 00:43:00 +0200 | euandreh | (~euandreh@179.214.113.107) (Ping timeout: 264 seconds) |
| 2022-10-05 00:43:43 +0200 | <goig> | What are the monoids of the category of endofunctors? Actually, we have more than one category of endofunctors no? As it's always in the respect to a given category |
| 2022-10-05 00:44:33 +0200 | <dminuoso> | An monoid M in some monoidal category (C, ⊗, I), is an object of C equipped with two morphisms of that category μ and η. So that monoid in a monoidal category too is a 3-tuple (M, η, η) |
| 2022-10-05 00:44:54 +0200 | <dminuoso> | goig: ^- given this definition, you dont have monoids in C, you have monoids in (C, ⊗, I) |
| 2022-10-05 00:45:03 +0200 | <dminuoso> | So you must first decide on a tensor |
| 2022-10-05 00:45:38 +0200 | <dminuoso> | Note that both 3-tuples here have additional laws that must be satisfied. |
| 2022-10-05 00:45:56 +0200 | <dminuoso> | (Both sets of laws look very similarly: associativity, left and right unit) |
| 2022-10-05 00:46:03 +0200 | <dminuoso> | Lots of monoidiality here. |
| 2022-10-05 00:46:04 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-10-05 00:46:51 +0200 | <monochrom> | We haven't even touched on how the word "tensor product" is also much overloaded >:) |
| 2022-10-05 00:47:17 +0200 | <dminuoso> | If we pick (:.:) (endofunctor composition) as its tensor, then *every object* M in the category C that you can equip with two morphisms μ and η, satifsying some particular laws |
| 2022-10-05 00:47:21 +0200 | <dminuoso> | is called such a monoid |
| 2022-10-05 00:47:34 +0200 | <dminuoso> | And in that particular monoidal category, every such object is called a monad |
| 2022-10-05 00:47:38 +0200 | <moonsheep> | as I understand it, the main difference between cereal and binary is that one runs on strict bytestrings and the other on lazy ones, is that correct? |
| 2022-10-05 00:47:43 +0200 | <dminuoso> | nope |
| 2022-10-05 00:47:50 +0200 | <dminuoso> | both really are designed for lazy bytestrings |
| 2022-10-05 00:48:18 +0200 | <dminuoso> | They have some surrounding code to adapt for strict bytestrings, but the internal machinery is really meant for streaming. |
| 2022-10-05 00:48:26 +0200 | <goig> | "So that monoid in a monoidal category too is a 3-tuple (M, η, η)" Is (M, \eta, \eta) a typo or not? |
| 2022-10-05 00:48:31 +0200 | <dminuoso> | Yes sorry |
| 2022-10-05 00:48:35 +0200 | <moonsheep> | cereal's `encode' is strict, you need to use `encodeLazy' to use a lazy bs |
| 2022-10-05 00:48:42 +0200 | <moonsheep> | whereas in binary `encode' is lazy by default |
| 2022-10-05 00:49:05 +0200 | <dminuoso> | moonsheep: that's not really the point of it. |
| 2022-10-05 00:49:49 +0200 | ksu | (~ksu@user/prtr) (Ping timeout: 252 seconds) |
| 2022-10-05 00:49:50 +0200 | <dminuoso> | Those are just functions to `put` into the builder |
| 2022-10-05 00:49:50 +0200 | <moonsheep> | and either way I want to (de)serialize a TCP stream of which I receive small strict bytestrings one at a time |
| 2022-10-05 00:49:59 +0200 | <dminuoso> | moonsheep: use flatparse then. |
| 2022-10-05 00:50:02 +0200 | <dminuoso> | for serialization |
| 2022-10-05 00:50:13 +0200 | <moonsheep> | oh I didn't know about flatparse |
| 2022-10-05 00:50:16 +0200 | <dminuoso> | *deserialization |
| 2022-10-05 00:50:20 +0200 | <dminuoso> | mason for deserialization |
| 2022-10-05 00:50:26 +0200 | <goig> | dminuoso What about return... |
| 2022-10-05 00:50:28 +0200 | <moonsheep> | is it like attoparsec's incremental capabilities? |
| 2022-10-05 00:50:29 +0200 | <dminuoso> | I was presented these two libraries for just the same problem, today! |
| 2022-10-05 00:50:32 +0200 | zebrag | (~chris@user/zebrag) (Ping timeout: 268 seconds) |
| 2022-10-05 00:50:35 +0200 | <moonsheep> | damn |
| 2022-10-05 00:51:02 +0200 | <moonsheep> | I asked a similar question the other day and someone suggested profunctors and bidirectional parsing |
| 2022-10-05 00:51:05 +0200 | <dminuoso> | moonsheep: flatparse is, under the hood, just a bytestring buffer and two pointers. |
| 2022-10-05 00:51:15 +0200 | hays | (rootvegeta@fsf/member/hays) (Ping timeout: 248 seconds) |
| 2022-10-05 00:51:16 +0200 | <moonsheep> | I've been playing around with them, but I'm having real trouble trying to get things to work |
| 2022-10-05 00:51:28 +0200 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 265 seconds) |
| 2022-10-05 00:51:35 +0200 | <dminuoso> | which means its extremely efficient, but it fundamentally can only work with a strict bytestring |
| 2022-10-05 00:51:54 +0200 | <dminuoso> | https://hackage.haskell.org/package/flatparse-0.3.5.1/docs/src/FlatParse.Basic.html#Parser |
| 2022-10-05 00:51:56 +0200 | <dminuoso> | newtype Parser e a = Parser {runParser# :: ForeignPtrContents -> Addr# -> Addr# -> Res# e a} |
| 2022-10-05 00:51:58 +0200 | <moonsheep> | can you keep incrementally feeding it small strict bytestrings though? |
| 2022-10-05 00:52:08 +0200 | <dminuoso> | Well you can just run new parsers every time. |
| 2022-10-05 00:52:20 +0200 | <dminuoso> | I do this for nested parsing |
| 2022-10-05 00:52:24 +0200 | <moonsheep> | but all those bytestrings are part of a larger stream |
| 2022-10-05 00:52:38 +0200 | <moonsheep> | they arrive in whatever chunks TCP feels lik¡e |
| 2022-10-05 00:52:41 +0200 | <dminuoso> | So I have a huge decoding tree, and while Im decoding, I discover the path in the tree. At each level I just `takeBs` and run a new parser |
| 2022-10-05 00:52:46 +0200 | <dminuoso> | Because of the construction, its all 0-copy |
| 2022-10-05 00:52:51 +0200 | <moonsheep> | hm |
| 2022-10-05 00:53:04 +0200 | <dminuoso> | moonsheep: then you fundamentally have a lazy bytestring problem. |
| 2022-10-05 00:53:16 +0200 | <dminuoso> | a lazy bytestring is just [ByteString] |
| 2022-10-05 00:53:16 +0200 | <moonsheep> | yes but I can't build a lazy bytestring from streaming data can I? |
| 2022-10-05 00:53:20 +0200 | <dminuoso> | Of course! |
| 2022-10-05 00:53:26 +0200 | <moonsheep> | how? |
| 2022-10-05 00:53:30 +0200 | <moonsheep> | fromChunks? |
| 2022-10-05 00:53:34 +0200 | <dminuoso> | Well rather |
| 2022-10-05 00:53:44 +0200 | <dminuoso> | Both binary and cereal let you deal with that |
| 2022-10-05 00:53:46 +0200 | <dminuoso> | they have a streaming interface |
| 2022-10-05 00:54:04 +0200 | <dminuoso> | You can either unsafeInterleaveIO and shove these chunks into a lazy list |
| 2022-10-05 00:54:12 +0200 | <dminuoso> | (which is absolutely terrible for a variety of reasons) |
| 2022-10-05 00:54:23 +0200 | <moonsheep> | what do you think of attoparsec? |
| 2022-10-05 00:54:34 +0200 | <moonsheep> | I always heard it was the best one of incremenntal parsing |
| 2022-10-05 00:54:44 +0200 | <dminuoso> | Or you use `binary` with `runGetIncremental` |
| 2022-10-05 00:54:47 +0200 | <moonsheep> | I know both binary and cereal have an incremental interface too |
| 2022-10-05 00:54:56 +0200 | <dminuoso> | I dont like attoparsec very much for what I do |
| 2022-10-05 00:55:07 +0200 | <dminuoso> | It has a static unoverridable hinting system |
| 2022-10-05 00:55:22 +0200 | <dminuoso> | Sorry no thats megaparsec |
| 2022-10-05 00:55:35 +0200 | <moonsheep> | what I don't like about attoparsec is that I'm not sure how to integrate it with a Putter in a way that makes sense |
| 2022-10-05 00:55:49 +0200 | <moonsheep> | hence why I'm tempted to just go with binary/cereal |
| 2022-10-05 00:55:53 +0200 | <dminuoso> | You will want to write both things separately anyway |
| 2022-10-05 00:55:54 +0200 | <moonsheep> | hence my original question |
| 2022-10-05 00:55:59 +0200 | <dminuoso> | so it doesnt matter whether you use different libraries |
| 2022-10-05 00:56:04 +0200 | <moonsheep> | yeah that's fair ig |
| 2022-10-05 00:56:10 +0200 | <dminuoso> | Do you need to incrementally produce output? |
| 2022-10-05 00:56:21 +0200 | <moonsheep> | the nice thing about binary/cereal is that they already have a fuckton of combinators that work really well |
| 2022-10-05 00:56:30 +0200 | <moonsheep> | dminuoso: no that's not necessary |
| 2022-10-05 00:56:33 +0200 | <moonsheep> | only input |
| 2022-10-05 00:56:40 +0200 | <dminuoso> | Consider `mason` for serialization then |
| 2022-10-05 00:56:45 +0200 | <moonsheep> | hmm, will do |
| 2022-10-05 00:56:48 +0200 | <dminuoso> | its extremely efficient too |
| 2022-10-05 00:56:50 +0200 | zebrag | (~chris@user/zebrag) |
| 2022-10-05 00:56:58 +0200 | <monochrom> | cereal and binary enjoyed a long period of cross pollination, so by now (even since years ago) they do the same thing. |
| 2022-10-05 00:56:58 +0200 | <moonsheep> | so then, does attoparsec+mason sound good? |
| 2022-10-05 00:56:59 +0200 | <dminuoso> | especially if the size is bounded or static |
| 2022-10-05 00:57:21 +0200 | <dminuoso> | if you're happy with attoparsec, sure |
| 2022-10-05 00:57:23 +0200 | <monochrom> | So I just use binary because it comes with GHC |
| 2022-10-05 00:57:24 +0200 | <moonsheep> | attoparsec for incremental parsing as the input arrives in small chunks, and mason for writing |
| 2022-10-05 00:57:36 +0200 | <moonsheep> | dminuoso: yeah I used it once for another purpose and it was fairly nice |
| 2022-10-05 00:57:53 +0200 | <moonsheep> | and really the one thing I absolutely need here is the incremental parsing, and hopefully good efficiency |
| 2022-10-05 00:57:56 +0200 | <moonsheep> | attoparsec claims to do both things |
| 2022-10-05 00:58:22 +0200 | <moonsheep> | monochrom: it does? |
| 2022-10-05 00:58:25 +0200 | <moonsheep> | I thought binary was a library |
| 2022-10-05 00:58:38 +0200 | <moonsheep> | https://hackage.haskell.org/package/binary |
| 2022-10-05 00:58:39 +0200 | <geekosaur> | a number of "boot libraries" come with ghc |
| 2022-10-05 00:58:43 +0200 | <moonsheep> | huh |
| 2022-10-05 00:58:44 +0200 | <dminuoso> | monochrom: Yeah its just very sad that binary has no sensible error recovery mechanism. :( |
| 2022-10-05 00:58:47 +0200 | <geekosaur> | because they're needed to build it |
| 2022-10-05 00:58:47 +0200 | <moonsheep> | I didn't know that |
| 2022-10-05 00:58:57 +0200 | <dminuoso> | And running nested parsers is very inefficient |
| 2022-10-05 00:59:01 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2022-10-05 00:59:28 +0200 | <moonsheep> | dminuoso: my error recovery policy is to simply terminate the connection, since both endpoints are expected to behave according to the protocol |
| 2022-10-05 00:59:29 +0200 | <geekosaur> | (binary is used to generate and read .hi module interface files, for instance) |
| 2022-10-05 00:59:42 +0200 | <moonsheep> | geekosaur: ah, that makes sense |
| 2022-10-05 01:00:32 +0200 | <dminuoso> | The only sensible error mechanism with `binary` is if you put ExceptT ontop of it. |
| 2022-10-05 01:01:02 +0200 | <dminuoso> | But since ExceptT is not CPSed, you can only pray for fusion |
| 2022-10-05 01:02:52 +0200 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2022-10-05 01:04:13 +0200 | <moonsheep> | by CPS do you mean continuation passing style? |
| 2022-10-05 01:04:26 +0200 | <dminuoso> | Yeah |
| 2022-10-05 01:05:10 +0200 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-10-05 01:06:35 +0200 | <moonsheep> | what exactly does CPS have to do witih the except monad? I thought it was simply a style of expressing "returning" something from a function that compilers used as an IR?(sorry I am really unsure about how this all works) |
| 2022-10-05 01:06:57 +0200 | <dminuoso> | newtype ExceptT e m a = ExceptT (m (Either e a)) |
| 2022-10-05 01:06:58 +0200 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) (Ping timeout: 268 seconds) |
| 2022-10-05 01:07:15 +0200 | <dminuoso> | So with this you will be producing an Either as the result of the monad |
| 2022-10-05 01:07:21 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-10-05 01:08:18 +0200 | <moonsheep> | so what is fusion and how does it relate to producing an Either instead of a continuation? |
| 2022-10-05 01:08:27 +0200 | <moonsheep> | (which is, I assume, what you're referring to? |
| 2022-10-05 01:08:32 +0200 | <moonsheep> | ) |
| 2022-10-05 01:08:45 +0200 | <dminuoso> | So fusion/deforestation is an optimization where, for example in lists, intermediate lists are gotten rid of |
| 2022-10-05 01:09:14 +0200 | <moonsheep> | oh so you mean like getting rid of the list in `sum [1..10]'? |
| 2022-10-05 01:09:34 +0200 | <dminuoso> | This is very important, as in Haskell a list is essentially `data List a = Cons a (List a) | Nil`, which means *every* single element has to have a heap representation |
| 2022-10-05 01:10:15 +0200 | <moonsheep> | and fusion doesn't work if you don't return a continuation? |
| 2022-10-05 01:10:31 +0200 | cheater | (~Username@user/cheater) (Remote host closed the connection) |
| 2022-10-05 01:10:33 +0200 | <moonsheep> | or rather return with a continuation I suppose |
| 2022-10-05 01:10:55 +0200 | <dminuoso> | I guess it could perhaps with sufficient sorcery, much of the list fusion in GHC relies on constructing lists via `build` |
| 2022-10-05 01:11:06 +0200 | <dminuoso> | build :: forall a . (forall b . (a -> b -> b) -> b -> b) -> [a] |
| 2022-10-05 01:11:18 +0200 | <moonsheep> | damn that's a cursed type signature |
| 2022-10-05 01:11:25 +0200 | <dminuoso> | It's very simple really |
| 2022-10-05 01:11:25 +0200 | <moonsheep> | is that higher rank? |
| 2022-10-05 01:11:27 +0200 | <dminuoso> | :t foldr |
| 2022-10-05 01:11:28 +0200 | <lambdabot> | Foldable t => (a -> b -> b) -> b -> t a -> b |
| 2022-10-05 01:11:30 +0200 | <geekosaur> | CPSed computations are almost trivial to fuse; anything else, you have to hope someone wrote an appropriate RULE that matches your use |
| 2022-10-05 01:11:55 +0200 | <geekosaur> | (or a built-in one like the one for basic list processing) |
| 2022-10-05 01:12:11 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-10-05 01:12:13 +0200 | <dminuoso> | moonsheep: observe that, we can think of a list as also being represented by `foldr` with the `t a` already applied. |
| 2022-10-05 01:12:33 +0200 | <moonsheep> | dminuoso: so by saying that except is not CPSed you meant that returning an either doesn't happen to match one of these predefined rules? |
| 2022-10-05 01:12:33 +0200 | <dminuoso> | So there is an isomorphism between: [a] and (a -> b -> b) -> b -> b |
| 2022-10-05 01:12:50 +0200 | <moonsheep> | that's hard to wrap my head around |
| 2022-10-05 01:13:00 +0200 | <geekosaur> | not quite |
| 2022-10-05 01:13:27 +0200 | <dminuoso> | moonsheep: viewed differently, the fundamental and characteristic thing you can do with a list is folding it. |
| 2022-10-05 01:13:32 +0200 | <geekosaur> | if it's CPSed then it can be fused. if it's not then it needs to match a RULE. there are a limited number of rules for (Except e a) |
| 2022-10-05 01:13:55 +0200 | <moonsheep> | right |
| 2022-10-05 01:14:00 +0200 | <geekosaur> | (there are many more for lists, some built-in) |
| 2022-10-05 01:14:10 +0200 | <jackdk> | moonsheep: http://data.tmorris.net/talks/list-folds/b30aa0fdff296c731bc5b1c824adf1d02b3b69d9/list-folds.pdf This is an excellent slide deck about this stuff - foldr "replaces the constructors" with functions |
| 2022-10-05 01:14:27 +0200 | <dminuoso> | moonsheep: so the trick with lists is, if you construct them via `build`, and you consume that list via `foldr` again, then you will achieve automatic short cut fusion |
| 2022-10-05 01:14:37 +0200 | <dminuoso> | there will not be a physical intermediate list |
| 2022-10-05 01:14:47 +0200 | <moonsheep> | that's interesting |
| 2022-10-05 01:14:59 +0200 | <moonsheep> | I had never seen folds as being such a fundamental universal property of lists |
| 2022-10-05 01:15:02 +0200 | <moonsheep> | merely as another utility function |
| 2022-10-05 01:15:11 +0200 | euandreh | (~euandreh@179.214.113.107) |
| 2022-10-05 01:15:24 +0200 | <geekosaur> | think of a fold (foldr in particular) as replacing [] with z and (:) with f |
| 2022-10-05 01:15:27 +0200 | <dminuoso> | but this relies on RULES, an optimization framework where you construct handwritten "match and replace" rules |
| 2022-10-05 01:15:41 +0200 | <moonsheep> | geekosaur: oh that makes so much sense, right |
| 2022-10-05 01:15:51 +0200 | <dminuoso> | moonsheep: in fact, this foldr representation is how you encode lists in Church representation in lambda calculus. |
| 2022-10-05 01:16:11 +0200 | <dminuoso> | or its one way at least. |
| 2022-10-05 01:16:43 +0200 | cheater | (~Username@user/cheater) |
| 2022-10-05 01:16:54 +0200 | <moonsheep> | I'm still not sure why `build' needs to be rank 2? |
| 2022-10-05 01:17:10 +0200 | <moonsheep> | why can't that `forall b.' be top-level? |
| 2022-10-05 01:17:12 +0200 | <dminuoso> | moonsheep: because it must be able to take any foldr type of function. |
| 2022-10-05 01:17:31 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-05 01:17:51 +0200 | <moonsheep> | how do you mean? |
| 2022-10-05 01:18:00 +0200 | <moonsheep> | "any folder type of the function"? |
| 2022-10-05 01:18:39 +0200 | <moonsheep> | hmm, maybe I shuold try to learn more about this type of more theoretical stuff |
| 2022-10-05 01:19:28 +0200 | <dminuoso> | monochrom: consider for a second how `build` would be used. |
| 2022-10-05 01:19:58 +0200 | <dminuoso> | Oops sorry, bad tab completion |
| 2022-10-05 01:20:17 +0200 | <dminuoso> | > myBuild g = g (:) [] |
| 2022-10-05 01:20:19 +0200 | <lambdabot> | <hint>:1:11: error: parse error on input ‘=’ |
| 2022-10-05 01:20:20 +0200 | <dminuoso> | @let myBuild g = g (:) [] |
| 2022-10-05 01:20:22 +0200 | <lambdabot> | Defined. |
| 2022-10-05 01:20:26 +0200 | <dminuoso> | :t myBuild |
| 2022-10-05 01:20:27 +0200 | <lambdabot> | ((a1 -> [a1] -> [a1]) -> [a2] -> t) -> t |
| 2022-10-05 01:20:28 +0200 | euandreh | (~euandreh@179.214.113.107) (Ping timeout: 265 seconds) |
| 2022-10-05 01:20:32 +0200 | <dminuoso> | monochrom: ^- this is the inferred rank 1 type. |
| 2022-10-05 01:20:39 +0200 | <moonsheep> | oh right |
| 2022-10-05 01:20:40 +0200 | <dminuoso> | Gosh again. I meant moonsheep. |
| 2022-10-05 01:20:54 +0200 | <dminuoso> | We cant just pin this to `b`, that would not type checkl |
| 2022-10-05 01:21:23 +0200 | <dminuoso> | :t foldr |
| 2022-10-05 01:21:24 +0200 | <lambdabot> | Foldable t => (a -> b -> b) -> b -> t a -> b |
| 2022-10-05 01:21:33 +0200 | <moonsheep> | hmm that makes sense I guess |
| 2022-10-05 01:21:41 +0200 | <moonsheep> | it's so hard to try to infer types in my head |
| 2022-10-05 01:21:42 +0200 | <EvanR> | dminuoso, sse2 is really just about registers? |
| 2022-10-05 01:21:50 +0200 | <dminuoso> | moonsheep: It might help to see the implicit quantification here. If we, assume the `t a` is implicitly applied, then this type becomes: |
| 2022-10-05 01:21:54 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) |
| 2022-10-05 01:22:12 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-34.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-10-05 01:22:13 +0200 | <dminuoso> | EvanR: No its about special execution units |
| 2022-10-05 01:22:18 +0200 | <dminuoso> | or execution ports, rather. |
| 2022-10-05 01:22:25 +0200 | <dminuoso> | but also special registers |
| 2022-10-05 01:23:18 +0200 | <dminuoso> | On modern AMD64 processors you have whats called register files, which are just large chunks of registers of different types. Nowadays you have about ~200 regular registers (used for RAX, RBX, RCX, etc...) |
| 2022-10-05 01:23:31 +0200 | <EvanR> | but same memory and same cache system |
| 2022-10-05 01:23:36 +0200 | <dminuoso> | And maybe another ~100 SIMD registers |
| 2022-10-05 01:23:55 +0200 | <dminuoso> | Or even more, really depends on the exact model |
| 2022-10-05 01:24:09 +0200 | <EvanR> | 200 registers, that would definitely simplify a few things |
| 2022-10-05 01:24:19 +0200 | jargon | (~jargon@174-22-201-96.phnx.qwest.net) |
| 2022-10-05 01:24:32 +0200 | euandreh | (~euandreh@179.214.113.107) |
| 2022-10-05 01:24:48 +0200 | <dminuoso> | Yup, but you have only 8 architectural registers |
| 2022-10-05 01:24:54 +0200 | <dminuoso> | That you can semantically observe |
| 2022-10-05 01:25:18 +0200 | <dminuoso> | Under the hood these registers get renamed at the reservation station |
| 2022-10-05 01:25:53 +0200 | <dminuoso> | so what you perceive as RAX for a given instruction, will inside the reservation station use physical register 17 maybe (say because that register happens to be free and not in use) |
| 2022-10-05 01:26:46 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Ping timeout: 260 seconds) |
| 2022-10-05 01:27:05 +0200 | <dminuoso> | This allows the CPU to do multiple calculations with RAX in parallel (say because you first add two numbers into RAX and store into memory, and then multpile 2 different unrelated numbers into RAX too and store into memory). |
| 2022-10-05 01:27:22 +0200 | <dminuoso> | There will be no dependency between the two, so they *can* be executed perfectly in parallel |
| 2022-10-05 01:27:32 +0200 | <dminuoso> | No reason for the latter to wait until the former has been completed. |
| 2022-10-05 01:27:52 +0200 | <moonsheep> | dminuoso: I'm having a lot of trouble understanding, that `b' isn't supposed to be anything other than `t a' right? |
| 2022-10-05 01:27:57 +0200 | <dminuoso> | SIMD uses special registers (that are much wider) and special execution ports (special circuitry that can do SIMD) |
| 2022-10-05 01:28:13 +0200 | <dminuoso> | moonsheep: no its different. |
| 2022-10-05 01:28:18 +0200 | <dminuoso> | the `t a` is already been applied. |
| 2022-10-05 01:28:39 +0200 | <EvanR> | dminuoso, I believe you about this story. But I find it astonishing that any time constraints can be satisfied as advertised |
| 2022-10-05 01:28:44 +0200 | <EvanR> | given how dynamic it is |
| 2022-10-05 01:29:18 +0200 | <moonsheep> | but the type of `g (:) []' is `b' which must then somehow unify with `[a]'? |
| 2022-10-05 01:29:22 +0200 | <EvanR> | what if there is no free register for a given task |
| 2022-10-05 01:29:39 +0200 | <dminuoso> | EvanR: then the pipeline will stall/block. |
| 2022-10-05 01:30:04 +0200 | <dminuoso> | EvanR: whats even cooler, there's something sort of STMish in this whole process. |
| 2022-10-05 01:30:20 +0200 | <dminuoso> | because it can speculatively execute things ahead of type |
| 2022-10-05 01:30:22 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-05 01:30:25 +0200 | <dminuoso> | and then commit or rollback |
| 2022-10-05 01:30:30 +0200 | <moonsheep> | oh btw sorry if I'm interrupting this more serious conversation |
| 2022-10-05 01:30:33 +0200 | <dminuoso> | and thats why you need that many registers |
| 2022-10-05 01:30:37 +0200 | euandreh | (~euandreh@179.214.113.107) (Ping timeout: 265 seconds) |
| 2022-10-05 01:30:37 +0200 | <EvanR> | no I'm interrupting, carry on |
| 2022-10-05 01:30:39 +0200 | <dminuoso> | moonsheep: no worries, keep on |
| 2022-10-05 01:32:12 +0200 | <dminuoso> | EvanR: The latest Intel generation is able to competently execute 6 instructions per clock cycle steadily. |
| 2022-10-05 01:32:35 +0200 | <dminuoso> | But of course, if you look at the entirety, it requires very careful code to do this. |
| 2022-10-05 01:33:26 +0200 | <dminuoso> | For example, you have typically one complex and 3 simple decoders. So your machine code should ideally produce 1 complex instruction and 3 simple instructions in a cycle. |
| 2022-10-05 01:33:34 +0200 | <dminuoso> | Otherwise you will bottleneck on the decoder stage |
| 2022-10-05 01:34:07 +0200 | <dminuoso> | (that's 6 instructions per clock cycle.. per core. of course) |
| 2022-10-05 01:34:52 +0200 | <moonsheep> | > myBuild $ const $ const 1 |
| 2022-10-05 01:34:53 +0200 | <lambdabot> | 1 |
| 2022-10-05 01:34:56 +0200 | <moonsheep> | > build $ const $ const 1 |
| 2022-10-05 01:34:58 +0200 | <lambdabot> | error: |
| 2022-10-05 01:34:58 +0200 | <lambdabot> | • Variable not in scope: build :: (b0 -> b1 -> a0) -> t |
| 2022-10-05 01:34:58 +0200 | <lambdabot> | • Perhaps you meant ‘buildG’ (imported from Data.Graph) |
| 2022-10-05 01:35:01 +0200 | <moonsheep> | huh |
| 2022-10-05 01:35:10 +0200 | <dminuoso> | But the latest generation has 6 decoders, and incremeneted to 12 execution ports |
| 2022-10-05 01:35:15 +0200 | <EvanR> | are these time guarantees or is it "you will probably be able to do 6 instructions per cycle" |
| 2022-10-05 01:35:17 +0200 | <geekosaur> | @index build |
| 2022-10-05 01:35:17 +0200 | <lambdabot> | GHC.Exts, Distribution.Simple.Build |
| 2022-10-05 01:35:24 +0200 | <dminuoso> | EvanR: Not even probably. |
| 2022-10-05 01:35:28 +0200 | <dminuoso> | Just with targeted code. |
| 2022-10-05 01:35:31 +0200 | <geekosaur> | you want the one in GHS.Exts |
| 2022-10-05 01:35:31 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 260 seconds) |
| 2022-10-05 01:35:34 +0200 | <dminuoso> | But locally it can occur. |
| 2022-10-05 01:35:38 +0200 | <geekosaur> | *GHC.Exts |
| 2022-10-05 01:35:43 +0200 | <EvanR> | not probably? |
| 2022-10-05 01:35:56 +0200 | <dminuoso> | You might have moments where a single core will execute 12 instructions in a single cycle |
| 2022-10-05 01:36:02 +0200 | <dminuoso> | Because you have 12 execution ports |
| 2022-10-05 01:36:05 +0200 | <moonsheep> | dminuoso: what's the difference? |
| 2022-10-05 01:36:23 +0200 | <moonsheep> | oh wait nevermind |
| 2022-10-05 01:36:30 +0200 | <moonsheep> | I just had a stroke disregard that |
| 2022-10-05 01:37:20 +0200 | argento | (~argent0@168-227-97-34.ptr.westnet.com.ar) |
| 2022-10-05 01:37:31 +0200 | goig | (~goig@202.91.42.7) (Quit: Client closed) |
| 2022-10-05 01:37:42 +0200 | <dminuoso> | EvanR: so on alder lake you have 1 complex and 5 simple decoders. In order to maintain that rate you have to a) have instructions of type [C,S,S,S,S,S,C,S,S,S,S,S,C,S,S,S,S,S.....], b) design all these instructions to use exactly the execution ports available |
| 2022-10-05 01:37:45 +0200 | <dminuoso> | Avoiding inter-dependencies |
| 2022-10-05 01:37:48 +0200 | <dminuoso> | And not use memory. |
| 2022-10-05 01:37:50 +0200 | <moonsheep> | btw how do you import modules with lambdabot? this the @index import them already? |
| 2022-10-05 01:37:59 +0200 | <dminuoso> | (Or at best use only things that are hot in L1) |
| 2022-10-05 01:38:27 +0200 | <dminuoso> | EvanR: this complex/simple thing is one of the things peephole optimizations passes in compilers will do by the way |
| 2022-10-05 01:38:32 +0200 | <geekosaur> | @let import GHC.Exts |
| 2022-10-05 01:38:33 +0200 | <lambdabot> | /sandbox/tmp/.L.hs:134:1: error: |
| 2022-10-05 01:38:33 +0200 | <lambdabot> | GHC.Exts: Can't be safely imported! The module itself isn't safe. |
| 2022-10-05 01:38:34 +0200 | <lambdabot> | | |
| 2022-10-05 01:38:34 +0200 | <dminuoso> | reorder instructions to keep the decoder stage happy |
| 2022-10-05 01:38:37 +0200 | <geekosaur> | welp |
| 2022-10-05 01:38:49 +0200 | <moonsheep> | @let import GHC.Base |
| 2022-10-05 01:38:50 +0200 | <geekosaur> | % import GHC.Exts |
| 2022-10-05 01:38:50 +0200 | <yahb2> | <no output> |
| 2022-10-05 01:38:50 +0200 | <lambdabot> | /sandbox/tmp/.L.hs:134:1: error: |
| 2022-10-05 01:38:51 +0200 | <lambdabot> | GHC.Base: Can't be safely imported! The module itself isn't safe. |
| 2022-10-05 01:38:51 +0200 | <lambdabot> | | |
| 2022-10-05 01:38:55 +0200 | <moonsheep> | > build $ const $ const 1 |
| 2022-10-05 01:38:57 +0200 | <lambdabot> | error: |
| 2022-10-05 01:38:57 +0200 | <lambdabot> | • Variable not in scope: build :: (b0 -> b1 -> a0) -> t |
| 2022-10-05 01:38:57 +0200 | <lambdabot> | • Perhaps you meant ‘buildG’ (imported from Data.Graph) |
| 2022-10-05 01:38:59 +0200 | <geekosaur> | % :t build |
| 2022-10-05 01:39:00 +0200 | <yahb2> | build :: (forall b. (a -> b -> b) -> b -> b) -> [a] |
| 2022-10-05 01:39:01 +0200 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2022-10-05 01:39:04 +0200 | <moonsheep> | hmm |
| 2022-10-05 01:39:10 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 01:39:10 +0200 | <geekosaur> | % build $ const $ const |
| 2022-10-05 01:39:11 +0200 | <yahb2> | <interactive>:232:9: error: ; • Occurs check: cannot construct the infinite type: b ~ b0 -> b ; Expected type: (a -> b -> b) -> b -> b ; Actual type: (a -> b -> b) -> b -> b0 -> b... |
| 2022-10-05 01:39:33 +0200 | <moonsheep> | what does % do? |
| 2022-10-05 01:39:42 +0200 | <geekosaur> | uses yahb2 instead of lambdabot |
| 2022-10-05 01:39:49 +0200 | <moonsheep> | what's the difference? |
| 2022-10-05 01:39:52 +0200 | <geekosaur> | yahb2 is a sandboxed ghci |
| 2022-10-05 01:39:52 +0200 | xff0x | (~xff0x@2405:6580:b080:900:5451:f081:9268:d7a) |
| 2022-10-05 01:39:55 +0200 | <moonsheep> | why can one run unsafe code? |
| 2022-10-05 01:39:57 +0200 | <moonsheep> | geekosaur: ah |
| 2022-10-05 01:39:59 +0200 | <dminuoso> | EvanR: instructions can also be reordered with knowledge about execution ports (in nehalem FP mul and SSE MUL is on the same execution port, so if you can move two adjacent FP mul and SSE mul instructions apart from each other, you can avoid bottlenecking on that execution port) |
| 2022-10-05 01:40:04 +0200 | <geekosaur> | lambdabot is a tightly constrained Mueval |
| 2022-10-05 01:40:10 +0200 | <moonsheep> | % build $ const $ const 1 |
| 2022-10-05 01:40:10 +0200 | <yahb2> | <interactive>:234:23: error: ; • No instance for (Num b) arising from the literal ‘1’ ; Possible fix: ; add (Num b) to the context of ; a type expected by the context: ;... |
| 2022-10-05 01:40:14 +0200 | <dminuoso> | EvanR: and thats the sort of thing the intel compiler is particularly good with |
| 2022-10-05 01:40:15 +0200 | <geekosaur> | (which you can look up on hackage) |
| 2022-10-05 01:40:48 +0200 | <moonsheep> | anyway so I think now I get the difference (just experimented a bit on local ghci, don't want to flood the channel) |
| 2022-10-05 01:41:22 +0200 | <moonsheep> | so if you don't do the explicit forall you can return anything you want from g, whereas with it it must actually be a list constructed with (:) and [] |
| 2022-10-05 01:41:24 +0200 | <moonsheep> | is that it? |
| 2022-10-05 01:41:49 +0200 | <dminuoso> | EvanR: now note, that if you do something like fetch memory and then do a lot of operations on that memory, you might not even have the chance for speculative execution. If that CPU has to wait 100 cycles for data to arrive into L1 from main memory, that's potentially 600 instructions wasted. |
| 2022-10-05 01:41:59 +0200 | <dminuoso> | the cpu will do.. nothing in that time. |
| 2022-10-05 01:42:12 +0200 | <dminuoso> | which is why cache aware code is so important |
| 2022-10-05 01:42:16 +0200 | euandreh | (~euandreh@179.214.113.107) |
| 2022-10-05 01:43:10 +0200 | <dminuoso> | moonsheep: rather, with `build` you could otherwise only accept a fold that specifically folds into lists. |
| 2022-10-05 01:43:21 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 252 seconds) |
| 2022-10-05 01:43:38 +0200 | <dminuoso> | by taking a function polymorphic over its return type, `build` is able to work with any list producer |
| 2022-10-05 01:43:55 +0200 | <moonsheep> | hmm, right |
| 2022-10-05 01:44:20 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 01:44:24 +0200 | <dminuoso> | moonsheep: In a function of rank-2-type, its the implementor of that function that will decide on the choice of the type variable |
| 2022-10-05 01:44:28 +0200 | <Axman6> | > build (\ |
| 2022-10-05 01:44:30 +0200 | <lambdabot> | <hint>:1:9: error: |
| 2022-10-05 01:44:30 +0200 | <lambdabot> | parse error (possibly incorrect indentation or mismatched brackets) |
| 2022-10-05 01:44:35 +0200 | <dminuoso> | the supplier has to provide a polymorphic one |
| 2022-10-05 01:44:46 +0200 | tomgus1 | (~tomgus1@2a02:c7e:4229:d900:dea6:32ff:fe3d:d1a3) (Quit: ZNC 1.8.2+deb2 - https://znc.in) |
| 2022-10-05 01:44:58 +0200 | <Axman6> | > build (\f b -> f 1 (f 2 (f 3 b))) |
| 2022-10-05 01:44:59 +0200 | <moonsheep> | oh right |
| 2022-10-05 01:45:00 +0200 | <lambdabot> | error: |
| 2022-10-05 01:45:00 +0200 | <lambdabot> | • Variable not in scope: |
| 2022-10-05 01:45:00 +0200 | <lambdabot> | build :: ((t1 -> t0 -> t0) -> t0 -> t0) -> t |
| 2022-10-05 01:45:06 +0200 | <Axman6> | % build (\f b -> f 1 (f 2 (f 3 b))) |
| 2022-10-05 01:45:06 +0200 | <yahb2> | [1,2,3] |
| 2022-10-05 01:45:09 +0200 | <dminuoso> | or *the caller |
| 2022-10-05 01:45:17 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-10-05 01:45:17 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-10-05 01:45:17 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2022-10-05 01:45:17 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-10-05 01:45:17 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-10-05 01:45:17 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-10-05 01:45:17 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-10-05 01:45:32 +0200 | tomgus1 | (~tomgus1@2e40cd7e.skybroadband.com) |
| 2022-10-05 01:45:36 +0200 | <dminuoso> | moonsheep: another view here with Axman6 presented, is that you can imagine this list to have "holes" in place of where (:) and [] otherwise are. |
| 2022-10-05 01:45:44 +0200 | califax | (~califax@user/califx) |
| 2022-10-05 01:46:04 +0200 | <dminuoso> | And `build` will just chose (:) and [] in those holes (thus rebuilding the list) |
| 2022-10-05 01:46:20 +0200 | <moonsheep> | yeah that makes sense |
| 2022-10-05 01:46:22 +0200 | <dminuoso> | > build (\f b -> 1 `f` (2 `f` (f `f` b))) |
| 2022-10-05 01:46:24 +0200 | <lambdabot> | error: |
| 2022-10-05 01:46:24 +0200 | <lambdabot> | • Variable not in scope: |
| 2022-10-05 01:46:24 +0200 | <lambdabot> | build :: ((t1 -> t0 -> t0) -> t0 -> t0) -> t |
| 2022-10-05 01:46:28 +0200 | <dminuoso> | % build (\f b -> 1 `f` (2 `f` (f `f` b))) |
| 2022-10-05 01:46:28 +0200 | <yahb2> | <interactive>:256:30: error: ; • Occurs check: cannot construct the infinite type: a ~ a -> b -> b ; • In the first argument of ‘f’, namely ‘f’ ; In the second argument of ‘f’, namely... |
| 2022-10-05 01:46:37 +0200 | <dminuoso> | % build (\f b -> 1 `f` (2 `f` (3 `f` b))) |
| 2022-10-05 01:46:38 +0200 | <yahb2> | [1,2,3] |
| 2022-10-05 01:46:48 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-10-05 01:46:55 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-05 01:47:05 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2022-10-05 01:47:08 +0200 | <dminuoso> | moonsheep: https://gist.github.com/dminuoso/af04270a918882b2cfa5b4eec74036ca |
| 2022-10-05 01:47:09 +0200 | <moonsheep> | funnily enough one of my earlier experiments was precisely a 1,2,3 list |
| 2022-10-05 01:47:22 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-10-05 01:47:22 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2022-10-05 01:47:27 +0200 | <moonsheep> | right |
| 2022-10-05 01:47:29 +0200 | <dminuoso> | If you align them like that, it becomes very obvious that you can turn the first into the second. |
| 2022-10-05 01:47:40 +0200 | <Axman6> | :t foldr |
| 2022-10-05 01:47:41 +0200 | <lambdabot> | Foldable t => (a -> b -> b) -> b -> t a -> b |
| 2022-10-05 01:47:48 +0200 | <moonsheep> | and the first one is just any old fold |
| 2022-10-05 01:48:06 +0200 | <dminuoso> | moonsheep: With that in mind, can you predict what this is going to do? |
| 2022-10-05 01:48:13 +0200 | <Axman6> | % :t \t -> build (\f b -> foldr f b t) |
| 2022-10-05 01:48:13 +0200 | <yahb2> | \t -> build (\f b -> foldr f b t) :: Foldable t => t a -> [a] |
| 2022-10-05 01:48:17 +0200 | <dminuoso> | foldr (:) [1] [1,2,3] |
| 2022-10-05 01:48:22 +0200 | <dminuoso> | moonsheep: ^- |
| 2022-10-05 01:48:28 +0200 | <dminuoso> | uhh |
| 2022-10-05 01:48:30 +0200 | <dminuoso> | foldr (:) [] [1,2,3] |
| 2022-10-05 01:48:32 +0200 | <dminuoso> | Sorry. |
| 2022-10-05 01:48:35 +0200 | <moonsheep> | rebuild the list |
| 2022-10-05 01:48:46 +0200 | <dminuoso> | Right. |
| 2022-10-05 01:48:51 +0200 | <moonsheep> | right that makes sense |
| 2022-10-05 01:49:10 +0200 | <dminuoso> | moonsheep: ANyway. Take note that each cons (:) will require a heap allocation |
| 2022-10-05 01:49:14 +0200 | <moonsheep> | since it's just doing 1 : 2 : 3 : [] |
| 2022-10-05 01:49:27 +0200 | <dminuoso> | So if you produce, consume, produce, consume lists constantly, this will generate a lot of allocations |
| 2022-10-05 01:49:28 +0200 | <moonsheep> | dminuoso: will that get optimized away with that fusion magic you were talking about? |
| 2022-10-05 01:49:29 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-05 01:49:36 +0200 | <dminuoso> | That's the thing |
| 2022-10-05 01:49:38 +0200 | <dminuoso> | You *want* it to go away |
| 2022-10-05 01:49:41 +0200 | <moonsheep> | right |
| 2022-10-05 01:50:06 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 260 seconds) |
| 2022-10-05 01:50:40 +0200 | <dminuoso> | If you construct the list via `build`, and then someone uses that list via `foldr`, then there is a special RULES thing that will just rewrite the `build` to go away, and just fuse the functions together. |
| 2022-10-05 01:50:49 +0200 | <dminuoso> | Making the intermediate list and all allocations go poof |
| 2022-10-05 01:51:04 +0200 | <moonsheep> | that's clever |
| 2022-10-05 01:51:06 +0200 | <dminuoso> | And suddenly gaining additional inilining opportunities |
| 2022-10-05 01:51:13 +0200 | <moonsheep> | so I assume build is used internally by lots of library functions? |
| 2022-10-05 01:51:22 +0200 | <dminuoso> | Yes |
| 2022-10-05 01:51:23 +0200 | <moonsheep> | making inlining suddenly a lot more productive? |
| 2022-10-05 01:51:24 +0200 | <EvanR> | can rewrite rules make my entire program disappear because it's equivalent to doing nothing xD |
| 2022-10-05 01:51:39 +0200 | <dminuoso> | moonsheep: consider Data.ByteString.unpack :: ByteString -> [Word8] |
| 2022-10-05 01:51:40 +0200 | <EvanR> | that would be the best |
| 2022-10-05 01:51:45 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 01:51:47 +0200 | <ski> | foldr cons nil (build f) = f cons nil |
| 2022-10-05 01:51:49 +0200 | <dminuoso> | moonsheep: unpack bs = build (unpackFoldr bs) https://hackage.haskell.org/package/bytestring-0.11.3.1/docs/src/Data.ByteString.html#unpack |
| 2022-10-05 01:51:53 +0200 | <moonsheep> | EvanR: "haskell code can have no side effects because no one will ever run it" -xkcd |
| 2022-10-05 01:52:02 +0200 | <EvanR> | lol |
| 2022-10-05 01:52:07 +0200 | <dminuoso> | Note how the list is build via unpackFoldr, and then presented via build |
| 2022-10-05 01:52:08 +0200 | <ski> | hah |
| 2022-10-05 01:52:14 +0200 | <dminuoso> | Such that if you decide to foldr over it, the list will go away. |
| 2022-10-05 01:52:21 +0200 | <EvanR> | xkcd should look at agda |
| 2022-10-05 01:52:27 +0200 | <dminuoso> | It will never exist in the first place. |
| 2022-10-05 01:52:53 +0200 | <dminuoso> | moonsheep: of course now the library author can write additional rules to make that foldr happen for you in special cases, such that you can pretend you're just doing normal list stuff. |
| 2022-10-05 01:52:55 +0200 | <moonsheep> | oh true, I would never have imagined it to have been implemented that way |
| 2022-10-05 01:52:59 +0200 | <monochrom> | But xkcd also needs to confine itself to talking about something people have heard of. |
| 2022-10-05 01:53:24 +0200 | <monochrom> | So let's say "haskell" is a social engineering compromise. |
| 2022-10-05 01:53:43 +0200 | <moonsheep> | wait what |
| 2022-10-05 01:53:46 +0200 | <dminuoso> | moonsheep: https://hackage.haskell.org/package/base-4.17.0.0/docs/src/GHC.Base.html#build |
| 2022-10-05 01:53:48 +0200 | <dminuoso> | take a quick look |
| 2022-10-05 01:53:57 +0200 | <dminuoso> | Look slightly below, you will see a section named RULES |
| 2022-10-05 01:54:09 +0200 | <dminuoso> | "fold/build" forall k z (g::forall b. (a->b->b) -> b -> b) . |
| 2022-10-05 01:54:11 +0200 | <moonsheep> | oh true |
| 2022-10-05 01:54:11 +0200 | <dminuoso> | foldr k z (build g) = g k z |
| 2022-10-05 01:54:14 +0200 | <moonsheep> | is that the GHC magic sauce? |
| 2022-10-05 01:54:15 +0200 | <dminuoso> | Without going into details, this means" |
| 2022-10-05 01:54:39 +0200 | <dminuoso> | If the optimizer ever sees `foldr k z (build g)` (matching the above signature) it is free to, without proving equality, statically replace it with `g k z` |
| 2022-10-05 01:54:49 +0200 | <dminuoso> | Thus the `build` call disappears entirely |
| 2022-10-05 01:54:53 +0200 | <dminuoso> | No list is ever constructed. |
| 2022-10-05 01:55:05 +0200 | <moonsheep> | that's really clever |
| 2022-10-05 01:55:58 +0200 | <dminuoso> | Actually its even stronger than "free to", it *will* replace it. |
| 2022-10-05 01:56:26 +0200 | <dminuoso> | GHC has, in addition, a lot of machinery to keep transforming code in happens of firing RULES like that. |
| 2022-10-05 01:56:26 +0200 | <moonsheep> | alright great and now I've forgotten why I even came here originally |
| 2022-10-05 01:56:29 +0200 | <moonsheep> | this is worse than wikiholes |
| 2022-10-05 01:56:31 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 260 seconds) |
| 2022-10-05 01:56:47 +0200 | <EvanR> | your original question was optimized away |
| 2022-10-05 01:56:55 +0200 | wonko | (~wjc@2a0e:1c80:11::50) (Ping timeout: 268 seconds) |
| 2022-10-05 01:56:58 +0200 | <moonsheep> | true |
| 2022-10-05 01:57:08 +0200 | <geekosaur> | you were originally asking why dminuoso wanted ExceptT to be CPS-transformed |
| 2022-10-05 01:57:14 +0200 | <moonsheep> | oh yeah |
| 2022-10-05 01:57:17 +0200 | <dminuoso> | moonsheep: by the way, also note that the `foldr` also disappears of course. |
| 2022-10-05 01:57:27 +0200 | <dminuoso> | Its not needed, because the folding is already there from the `build` producer side. |
| 2022-10-05 01:57:33 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 01:57:37 +0200 | <moonsheep> | yeah that makes sense |
| 2022-10-05 01:57:39 +0200 | <dminuoso> | So we can just use that one, and fold it with whatever the original folder wanted. |
| 2022-10-05 01:57:40 +0200 | bgamari | (~bgamari@64.223.132.120) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-10-05 01:58:43 +0200 | <dminuoso> | moonsheep: with that machinery in place, you can potentially end in situations where instead of rebuilding a list countless times, instead you end up with a composed function `k` (from above) that does a bunch of things in a row |
| 2022-10-05 01:59:07 +0200 | <dminuoso> | its a very important optimization to make lists with the incredible allocation overhead usable |
| 2022-10-05 01:59:14 +0200 | <geekosaur> | and before that why it's difficult to interrupt a binary/cereal put, iirc (may have been get) |
| 2022-10-05 01:59:32 +0200 | <geekosaur> | which is where the ExceptT came in |
| 2022-10-05 01:59:40 +0200 | <moonsheep> | yeah I remember that |
| 2022-10-05 01:59:40 +0200 | <moonsheep> | anyway |
| 2022-10-05 01:59:56 +0200 | <moonsheep> | off I go I guess, I'll try mason+attoparsec |
| 2022-10-05 02:00:26 +0200 | <moonsheep> | maybe one day the GHC internals and all this magic sauce will stop being a mystery to me |
| 2022-10-05 02:00:32 +0200 | <dminuoso> | Heh |
| 2022-10-05 02:00:58 +0200 | <dminuoso> | I recall a talk by Simon Peyton Jones, where he explained that nobody really knows much about *why* the simplifier works so good. It' |
| 2022-10-05 02:01:17 +0200 | <dminuoso> | It's mostly just tweaking, observing core, and tweaking some more, turning knobs, until it produces better output than before. |
| 2022-10-05 02:01:19 +0200 | <dminuoso> | :p |
| 2022-10-05 02:01:29 +0200 | <moonsheep> | engineering in a nutshell |
| 2022-10-05 02:01:35 +0200 | <EvanR> | The simplifier. It's evolving |
| 2022-10-05 02:01:39 +0200 | <dminuoso> | No that's neural network development in a nutshell. |
| 2022-10-05 02:01:57 +0200 | <moonsheep> | well neural network development is just a very extreme case |
| 2022-10-05 02:02:03 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 252 seconds) |
| 2022-10-05 02:02:20 +0200 | <moonsheep> | and an incredibly cumbersome one too, since every time you slightly tweak a hyperparameter you have to wait 2 hours for the results |
| 2022-10-05 02:02:38 +0200 | <dminuoso> | I mean yeah, most of the simplifier passes are based on published work and very well understood, but each simplifier pass turns code around, which can undo chances for other things (like RULES or inlining) to fire, or set them up. |
| 2022-10-05 02:02:47 +0200 | <dminuoso> | And its a very delicate balancing based mostly on trial |
| 2022-10-05 02:03:19 +0200 | <dminuoso> | So one simplifier might, by itself, do very good things, but maybe ruin inlining opportunities |
| 2022-10-05 02:04:05 +0200 | <moonsheep> | jesus that sounds like a nightmare |
| 2022-10-05 02:06:48 +0200 | <dminuoso> | https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/opt-ordering#3-want-full-laziness-b… |
| 2022-10-05 02:07:08 +0200 | fmgornick | (~fmgornick@2607:ea00:107:3c07:5923:76a4:72ae:d74d) |
| 2022-10-05 02:07:16 +0200 | <fmgornick> | ?src >>= |
| 2022-10-05 02:07:16 +0200 | <lambdabot> | Source not found. You speak an infinite deal of nothing. |
| 2022-10-05 02:07:33 +0200 | <fmgornick> | ?src (>>=) |
| 2022-10-05 02:07:34 +0200 | <lambdabot> | Source not found. My brain just exploded |
| 2022-10-05 02:07:44 +0200 | fmgornick | (~fmgornick@2607:ea00:107:3c07:5923:76a4:72ae:d74d) (Client Quit) |
| 2022-10-05 02:07:45 +0200 | <EvanR> | (>>=) is a class method |
| 2022-10-05 02:07:56 +0200 | <EvanR> | he's gone already |
| 2022-10-05 02:08:42 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 02:12:16 +0200 | euandreh | (~euandreh@179.214.113.107) (Ping timeout: 260 seconds) |
| 2022-10-05 02:12:29 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::778c) |
| 2022-10-05 02:13:22 +0200 | <zero> | ?src Monad |
| 2022-10-05 02:13:22 +0200 | <lambdabot> | class Applicative m => Monad m where |
| 2022-10-05 02:13:22 +0200 | <lambdabot> | -- Note: Applicative wasn't a superclass before GHC 7.10 |
| 2022-10-05 02:13:22 +0200 | <lambdabot> | (>>=) :: m a -> (a -> m b) -> m b |
| 2022-10-05 02:13:22 +0200 | <lambdabot> | (>>) :: m a -> m b -> m b |
| 2022-10-05 02:13:22 +0200 | <lambdabot> | return :: a -> m a |
| 2022-10-05 02:13:24 +0200 | <lambdabot> | fail :: String -> m a |
| 2022-10-05 02:13:36 +0200 | <zero> | eew fail |
| 2022-10-05 02:14:29 +0200 | <dminuoso> | monochrom: Okay I think I know why I said "it was removed". join was bound to be included in the AMP, but was abolished due to the fundamental GND interaction. |
| 2022-10-05 02:14:48 +0200 | <dminuoso> | Maybe I had that in mind. |
| 2022-10-05 02:15:19 +0200 | xff0x | (~xff0x@2405:6580:b080:900:5451:f081:9268:d7a) (Ping timeout: 250 seconds) |
| 2022-10-05 02:15:41 +0200 | euandreh | (~euandreh@179.214.113.107) |
| 2022-10-05 02:15:56 +0200 | jmorris | (uid537181@id-537181.uxbridge.irccloud.com) |
| 2022-10-05 02:17:12 +0200 | <monochrom> | OK yeah. |
| 2022-10-05 02:17:27 +0200 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) |
| 2022-10-05 02:17:40 +0200 | <monochrom> | join wanted to join but was returned at the last minute. |
| 2022-10-05 02:18:13 +0200 | <EvanR> | return is still in the Monad class? |
| 2022-10-05 02:18:20 +0200 | <monochrom> | meanwhile, >>= binds tightly as ever. |
| 2022-10-05 02:18:28 +0200 | <Axman6> | If that were me, I would've felt pretty bound up inside |
| 2022-10-05 02:18:29 +0200 | <monochrom> | Yes. |
| 2022-10-05 02:19:24 +0200 | <EvanR> | is return there for compatibility or is there a performance reason |
| 2022-10-05 02:19:49 +0200 | <monochrom> | Your heart would feel like flattened |
| 2022-10-05 02:20:09 +0200 | <jackdk> | If you move return out, you break code. |
| 2022-10-05 02:20:11 +0200 | <dminuoso> | It was kept for pure intensions. |
| 2022-10-05 02:21:07 +0200 | <geekosaur> | the problem is that when Applicative was added as a "superclass", a lot of programs backformed their Applicative instances as { pure - return; <*> = ap } |
| 2022-10-05 02:21:20 +0200 | <dminuoso> | You ruined a streak of puns there, geekosaur. |
| 2022-10-05 02:21:34 +0200 | <Axman6> | fail |
| 2022-10-05 02:21:53 +0200 | <geekosaur> | no, fail's gone :þ |
| 2022-10-05 02:21:53 +0200 | <dminuoso> | Maybe we can fix it? |
| 2022-10-05 02:22:42 +0200 | <geekosaur> | the Monad of no `return` proposal is still out there somewhere, though |
| 2022-10-05 02:23:16 +0200 | <geekosaur> | but I think it may have run into a brick wall of "too many code-breaking changes" |
| 2022-10-05 02:23:48 +0200 | <geekosaur> | there was a near-revolt over that recently |
| 2022-10-05 02:23:56 +0200 | <geekosaur> | (like, past year or so) |
| 2022-10-05 02:25:07 +0200 | <dminuoso> | Its bizarre, JavaScript developers get breaking code so often, they just ship broken code into production without testing. |
| 2022-10-05 02:25:13 +0200 | <dminuoso> | It's the norm for them. |
| 2022-10-05 02:25:45 +0200 | <monochrom> | It is OK because everyone blocks javascript anyway. |
| 2022-10-05 02:26:08 +0200 | <monochrom> | Right? "Javascript has no side effects because the code is not run." >:) |
| 2022-10-05 02:26:36 +0200 | <dminuoso> | By the way, what really surprises me about javascript, is how NPM do not compute a coherent build plan. So you can and frequently have multiple versions of the same library around. |
| 2022-10-05 02:26:39 +0200 | <dminuoso> | And this rarely causes problems |
| 2022-10-05 02:26:47 +0200 | <dminuoso> | I've never been able to understand why its not a big problem for them. |
| 2022-10-05 02:27:17 +0200 | <Axman6> | > ('a':) |
| 2022-10-05 02:27:19 +0200 | <lambdabot> | <[Char] -> [Char]> |
| 2022-10-05 02:27:21 +0200 | <Axman6> | > do fix it |
| 2022-10-05 02:27:23 +0200 | <lambdabot> | error: |
| 2022-10-05 02:27:23 +0200 | <lambdabot> | • Variable not in scope: it :: a -> a |
| 2022-10-05 02:27:23 +0200 | <lambdabot> | • Perhaps you meant one of these: |
| 2022-10-05 02:27:28 +0200 | <geekosaur> | because everyone ignores the errors anyway |
| 2022-10-05 02:27:31 +0200 | <Axman6> | y u no GHCi |
| 2022-10-05 02:27:42 +0200 | <geekosaur> | (do yourself a favor and never open the JS console in your browser) |
| 2022-10-05 02:27:45 +0200 | hays | (rootvegeta@fsf/member/hays) |
| 2022-10-05 02:27:51 +0200 | <geekosaur> | % do fix it |
| 2022-10-05 02:27:52 +0200 | <yahb2> | <interactive>:262:8: error: ; • Couldn't match expected type ‘a -> a’ with actual type ‘[a0]’ ; • In the first argument of ‘fix’, namely ‘it’ ; In a stmt of a 'do' block: fix it ; ... |
| 2022-10-05 02:27:59 +0200 | <dminuoso> | I regularly do, and honestly for the most part web sites do function. |
| 2022-10-05 02:28:04 +0200 | <jackdk> | % fix error |
| 2022-10-05 02:28:05 +0200 | <yahb2> | "*** Exception: *** Exception: *** Exception: *** Exception: *** Exception: *** Exception: *** Exception: *** Exception: *** Exception: *** Exception: *** Exception: *** Exception: *** Exception: *... |
| 2022-10-05 02:28:16 +0200 | <moonsheep> | dminuoso: I guess it's not a problem for them because errors pass silently- worse they're gonna get is a bunch of errors in the browser console, which no one ever bothers to check anyway |
| 2022-10-05 02:28:43 +0200 | <dminuoso> | Or maybe these errors do get caught in testing/staging *shrugs* |
| 2022-10-05 02:29:00 +0200 | <dminuoso> | Maybe JavaScript developers spend a day of their week fixing incoherent build plan bugs *shrugs* |
| 2022-10-05 02:29:16 +0200 | bgamari | (~bgamari@64.223.130.138) |
| 2022-10-05 02:29:45 +0200 | <monochrom> | If errors don't abort program execution, then you can always monkey-patch moar code after the error-raising code to get things done. |
| 2022-10-05 02:29:58 +0200 | <moonsheep> | if you open the console on *any* webpage and wait a bit you're gonna see a bunch of errors and warings pop up |
| 2022-10-05 02:30:15 +0200 | <geekosaur> | and most of the time there's like a 1-line difference between those versions anyway |
| 2022-10-05 02:30:48 +0200 | <moonsheep> | hell even google search seems to do a CORS request to play.google.com (for some reason?) |
| 2022-10-05 02:31:08 +0200 | <dminuoso> | Or maybe its just uncommon to pass data around-as-they-are? Do JavaScriptees perhaps always destructure library data? |
| 2022-10-05 02:31:14 +0200 | <monochrom> | The result is consistent with your observation: The web page functions as advertised, but inefficiently. |
| 2022-10-05 02:31:35 +0200 | <moonsheep> | "The web page functions as advertised" yeah, like 90% of the time |
| 2022-10-05 02:31:47 +0200 | <moonsheep> | sometimes you'll just click buttons and they'll randomly decide to not work |
| 2022-10-05 02:31:55 +0200 | <moonsheep> | or to play the fancy click animation and then hang |
| 2022-10-05 02:32:08 +0200 | <moonsheep> | ¯\_(ツ)_/¯ |
| 2022-10-05 02:33:16 +0200 | <moonsheep> | whatever, javascript was one big hack since the very beginning, and at this point in time it's just a huge amorphous mass of kludges, JIT and bizarre weak typing hijinks |
| 2022-10-05 02:33:25 +0200 | <moonsheep> | I really do pity the v8 developeers |
| 2022-10-05 02:34:27 +0200 | <geekosaur> | actually I think the very first version wasn't a hack. it was also mostly a lisp dialect. then netscape decided they needed to ride java's coattails |
| 2022-10-05 02:34:43 +0200 | <EvanR> | computers became too powerful and fast. The web was invented to balance us out |
| 2022-10-05 02:35:06 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2022-10-05 02:35:08 +0200 | <dminuoso> | geekosaur: the first version was a hack |
| 2022-10-05 02:35:09 +0200 | <geekosaur> | software bloats to overfill the available infrastructure |
| 2022-10-05 02:35:26 +0200 | <dminuoso> | When you're tasked to write a scripting engine for a browser in 10 days |
| 2022-10-05 02:35:28 +0200 | <dminuoso> | This is what you get. |
| 2022-10-05 02:36:12 +0200 | <EvanR> | so the legend goes, and it continues to evolve xD |
| 2022-10-05 02:36:28 +0200 | <dminuoso> | It's not a legend though. |
| 2022-10-05 02:36:30 +0200 | <moonsheep> | honestly, I would've much rather they just had put java applets in a sandbox than whatever happened |
| 2022-10-05 02:36:35 +0200 | <dminuoso> | That is its actual history |
| 2022-10-05 02:37:00 +0200 | <dminuoso> | Its why you have only float and no integral numbers. It was a simple time saving decision since two numeric types take more time than just one. |
| 2022-10-05 02:37:02 +0200 | <moonsheep> | at least thought was put into the design of java |
| 2022-10-05 02:37:03 +0200 | <EvanR> | the javascript guy was asked to write a scripting engine, so he spent the entire weekend in a desert high on peyote and javascript was the result |
| 2022-10-05 02:37:16 +0200 | <probie> | There's a usable language inside JS, the problem is that other people keep using things outside that when they write JS |
| 2022-10-05 02:37:26 +0200 | <monochrom> | Maybe it was inspired by Applesoft BASIC? >:) |
| 2022-10-05 02:37:56 +0200 | <probie> | s/inside JS/inside ES6/ |
| 2022-10-05 02:37:58 +0200 | <EvanR> | apparently javascript now has a for each construct, I am told |
| 2022-10-05 02:38:03 +0200 | <dminuoso> | probie: https://i.redd.it/h7nt4keyd7oy.jpg |
| 2022-10-05 02:38:05 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2022-10-05 02:38:13 +0200 | <EvanR> | it only too 30 years |
| 2022-10-05 02:38:17 +0200 | <monochrom> | hahaha |
| 2022-10-05 02:38:18 +0200 | <dminuoso> | That picture captures is better than a thousand words. |
| 2022-10-05 02:38:50 +0200 | <EvanR> | Flanagan JS, Crockford JS |
| 2022-10-05 02:38:56 +0200 | <moonsheep> | dminuoso: damn I was looking for that picture |
| 2022-10-05 02:39:40 +0200 | <moonsheep> | has anyone actually read javascript: the good parts? |
| 2022-10-05 02:40:04 +0200 | <EvanR> | that it has good parts is the implication I got |
| 2022-10-05 02:40:17 +0200 | <dminuoso> | Honestly even the good parts sit on a rotten core. |
| 2022-10-05 02:40:35 +0200 | <dminuoso> | The absolutely absurd equality triangles are just one example. |
| 2022-10-05 02:40:55 +0200 | <probie> | I like that the result of `new Boolean(false)` is a truthy value |
| 2022-10-05 02:41:02 +0200 | <dminuoso> | It's quite literally PHP-levels of ergonomics when equality is so bad, that instead of fixing equality you get a different operator you should be using instead. |
| 2022-10-05 02:41:33 +0200 | <moonsheep> | anyway, good night folks |
| 2022-10-05 02:41:51 +0200 | moonsheep | (~user@user/moonsheep) (ERC 5.4 (IRC client for GNU Emacs 28.2)) |
| 2022-10-05 02:42:16 +0200 | <probie> | dminuoso: so just don't use it outside of `== null` for when you want it to be true for both `null` and `undefined`. Of course, why is there both `null` and `undefined`... |
| 2022-10-05 02:43:31 +0200 | <Clinton[m]> | I'm pretty sure this is a function (or at least a relatively simple composition of functions) but I'm not sure what it is:... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/a6a4b14a44af6f5199c262e753f8037e9f67…>) |
| 2022-10-05 02:44:14 +0200 | <Clinton[m]> | Is it some fold over the state monad shrugs |
| 2022-10-05 02:44:36 +0200 | <monochrom> | I am not sure you don't mean (s -> a -> (s, a)) -> s -> a -> [a] |
| 2022-10-05 02:44:53 +0200 | <dminuoso> | :t mapAccumL |
| 2022-10-05 02:44:54 +0200 | <lambdabot> | Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) |
| 2022-10-05 02:45:27 +0200 | <dminuoso> | It's a variant of this Clinton[m] |
| 2022-10-05 02:45:39 +0200 | <Clinton[m]> | dminuoso: Oh that's beautiful perfect thanks! |
| 2022-10-05 02:45:47 +0200 | <Clinton[m]> | Thought I had saw it somewhere |
| 2022-10-05 02:48:05 +0200 | euandreh | (~euandreh@179.214.113.107) (Remote host closed the connection) |
| 2022-10-05 02:49:37 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds) |
| 2022-10-05 02:50:23 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2022-10-05 02:51:04 +0200 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) (Quit: xff0x) |
| 2022-10-05 02:53:18 +0200 | xff0x | (~xff0x@2405:6580:b080:900:bf74:abfd:4cfe:d90f) |
| 2022-10-05 02:56:06 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-10-05 02:56:07 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-10-05 02:56:07 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-10-05 02:56:07 +0200 | euandreh | (~euandreh@179.214.113.107) |
| 2022-10-05 03:00:29 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-10-05 03:01:17 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-10-05 03:01:52 +0200 | vglfr | (~vglfr@145.224.100.190) (Ping timeout: 246 seconds) |
| 2022-10-05 03:04:40 +0200 | andreabedini | (~andreabed@8s8kj681vht2qj3xkwc5.ip6.superloop.com) |
| 2022-10-05 03:05:56 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 260 seconds) |
| 2022-10-05 03:06:48 +0200 | sympt | (~sympt@user/sympt) (Ping timeout: 265 seconds) |
| 2022-10-05 03:07:24 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 03:07:54 +0200 | dcoutts__ | (~duncan@host86-170-66-8.range86-170.btcentralplus.com) |
| 2022-10-05 03:08:57 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 258 seconds) |
| 2022-10-05 03:09:08 +0200 | Guest1698 | jbayardo |
| 2022-10-05 03:10:36 +0200 | dcoutts_ | (~duncan@host86-177-125-45.range86-177.btcentralplus.com) (Ping timeout: 260 seconds) |
| 2022-10-05 03:10:51 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-10-05 03:14:03 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2022-10-05 03:15:57 +0200 | xff0x | (~xff0x@2405:6580:b080:900:bf74:abfd:4cfe:d90f) (Ping timeout: 268 seconds) |
| 2022-10-05 03:16:58 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-10-05 03:17:01 +0200 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) (Ping timeout: 260 seconds) |
| 2022-10-05 03:18:46 +0200 | euandreh | (~euandreh@179.214.113.107) (Ping timeout: 260 seconds) |
| 2022-10-05 03:18:53 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 265 seconds) |
| 2022-10-05 03:19:02 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-05 03:19:35 +0200 | euandreh | (~euandreh@179.214.113.107) |
| 2022-10-05 03:20:40 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Read error: Connection reset by peer) |
| 2022-10-05 03:21:48 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-10-05 03:23:15 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-10-05 03:24:33 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 252 seconds) |
| 2022-10-05 03:25:00 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 264 seconds) |
| 2022-10-05 03:26:05 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 03:28:40 +0200 | andreabedini | (~andreabed@8s8kj681vht2qj3xkwc5.ip6.superloop.com) (Quit: WeeChat 3.6) |
| 2022-10-05 03:29:38 +0200 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) |
| 2022-10-05 03:30:20 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-05 03:31:27 +0200 | off^ | (~off@c-76-17-6-165.hsd1.ga.comcast.net) |
| 2022-10-05 03:38:48 +0200 | beteigeuze | (~Thunderbi@2001:8a0:61b5:6101:f0c:e4e3:bfdc:91df) (Ping timeout: 264 seconds) |
| 2022-10-05 03:47:27 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-10-05 03:48:38 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-05 03:58:23 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Quit: Lost terminal) |
| 2022-10-05 03:59:33 +0200 | vglfr | (~vglfr@145.224.100.190) |
| 2022-10-05 04:01:18 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2022-10-05 04:01:40 +0200 | codaraxis__ | (~codaraxis@user/codaraxis) |
| 2022-10-05 04:04:38 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 268 seconds) |
| 2022-10-05 04:05:46 +0200 | codaraxis___ | (~codaraxis@user/codaraxis) (Ping timeout: 265 seconds) |
| 2022-10-05 04:06:53 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2022-10-05 04:08:33 +0200 | td_ | (~td@muedsl-82-207-238-106.citykom.de) (Ping timeout: 252 seconds) |
| 2022-10-05 04:10:18 +0200 | td_ | (~td@94.134.91.45) |
| 2022-10-05 04:15:31 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 252 seconds) |
| 2022-10-05 04:15:52 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2022-10-05 04:15:52 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-10-05 04:15:52 +0200 | finn_elija | FinnElija |
| 2022-10-05 04:26:32 +0200 | k8yun | (~k8yun@user/k8yun) |
| 2022-10-05 04:28:21 +0200 | jbayardo | (~Guest1698@20.83.116.49) (Quit: https://convos.chat) |
| 2022-10-05 04:28:45 +0200 | jbayardo | (~jbayardo@20.83.116.49) |
| 2022-10-05 04:29:45 +0200 | lagash_ | (lagash@lagash.shelltalk.net) (Remote host closed the connection) |
| 2022-10-05 04:30:16 +0200 | lagash | (lagash@lagash.shelltalk.net) |
| 2022-10-05 04:30:31 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-05 04:33:07 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 252 seconds) |
| 2022-10-05 04:36:13 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-05 04:37:16 +0200 | Guest26 | (~Guest26@202.119.42.88) |
| 2022-10-05 04:38:06 +0200 | Guest26 | (~Guest26@202.119.42.88) (Client Quit) |
| 2022-10-05 04:41:42 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-10-05 04:45:54 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 04:46:29 +0200 | darkstardevx | (~darkstard@50.126.124.156) |
| 2022-10-05 04:47:50 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) (Remote host closed the connection) |
| 2022-10-05 04:48:27 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) |
| 2022-10-05 04:50:22 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 246 seconds) |
| 2022-10-05 04:52:05 +0200 | argento | (~argent0@168-227-97-34.ptr.westnet.com.ar) (Remote host closed the connection) |
| 2022-10-05 04:55:02 +0200 | rekahsoft | (~rekahsoft@142.189.68.220) |
| 2022-10-05 04:55:26 +0200 | rekahsoft | (~rekahsoft@142.189.68.220) (Remote host closed the connection) |
| 2022-10-05 04:55:42 +0200 | jmorris | (uid537181@id-537181.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-10-05 04:56:01 +0200 | rekahsoft | (~rekahsoft@142.189.68.220) |
| 2022-10-05 04:56:58 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 04:58:19 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 268 seconds) |
| 2022-10-05 05:00:24 +0200 | rekahsoft | (~rekahsoft@142.189.68.220) (Ping timeout: 264 seconds) |
| 2022-10-05 05:01:36 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 264 seconds) |
| 2022-10-05 05:03:19 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 05:04:41 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-05 05:05:43 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.5) |
| 2022-10-05 05:08:40 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-10-05 05:08:53 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-10-05 05:09:45 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-05 05:10:00 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-05 05:10:10 +0200 | k8yun | (~k8yun@user/k8yun) (Quit: Leaving) |
| 2022-10-05 05:13:30 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-10-05 05:13:30 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-10-05 05:13:30 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-10-05 05:22:55 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-05 05:35:40 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 265 seconds) |
| 2022-10-05 05:37:55 +0200 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2022-10-05 05:40:22 +0200 | califax | (~califax@user/califx) (Ping timeout: 258 seconds) |
| 2022-10-05 05:41:39 +0200 | califax | (~califax@user/califx) |
| 2022-10-05 05:45:25 +0200 | k8yun | (~k8yun@user/k8yun) |
| 2022-10-05 05:50:34 +0200 | Vajb | (~Vajb@2001:999:504:1841:9e47:1ec7:a52e:1d57) (Read error: Connection reset by peer) |
| 2022-10-05 05:50:42 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 268 seconds) |
| 2022-10-05 05:50:52 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2022-10-05 05:52:35 +0200 | inversed | (~inversed@90.209.137.56) (Ping timeout: 268 seconds) |
| 2022-10-05 05:53:10 +0200 | inversed | (~inversed@90.209.137.56) |
| 2022-10-05 06:02:53 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-10-05 06:04:04 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-05 06:05:53 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-10-05 06:06:07 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 268 seconds) |
| 2022-10-05 06:07:15 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-10-05 06:07:49 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-05 06:13:23 +0200 | Vajb | (~Vajb@2001:999:504:1841:9e47:1ec7:a52e:1d57) |
| 2022-10-05 06:19:51 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-10-05 06:24:58 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 265 seconds) |
| 2022-10-05 06:37:12 +0200 | talismanick | (~talismani@2601:200:c100:c9e0::24ac) |
| 2022-10-05 06:37:50 +0200 | off^ | (~off@c-76-17-6-165.hsd1.ga.comcast.net) (Remote host closed the connection) |
| 2022-10-05 06:42:36 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-10-05 06:52:15 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.) |
| 2022-10-05 06:53:12 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 06:54:45 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-05 06:57:25 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 250 seconds) |
| 2022-10-05 06:57:50 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 265 seconds) |
| 2022-10-05 06:59:34 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2022-10-05 07:07:30 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 265 seconds) |
| 2022-10-05 07:10:47 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 07:12:35 +0200 | arkeet | (~arkeet@moriya.ca) (Ping timeout: 248 seconds) |
| 2022-10-05 07:13:08 +0200 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) |
| 2022-10-05 07:13:47 +0200 | arkeet | (~arkeet@moriya.ca) |
| 2022-10-05 07:15:14 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 265 seconds) |
| 2022-10-05 07:15:20 +0200 | k8yun | (~k8yun@user/k8yun) (Quit: Leaving) |
| 2022-10-05 07:20:20 +0200 | Infinite | (~Infinite@106.51.13.146) |
| 2022-10-05 07:21:00 +0200 | ksu | (~ksu@user/prtr) |
| 2022-10-05 07:21:44 +0200 | chomwitt | (~chomwitt@2a02:587:dc14:f500:668b:b8eb:ac49:50a6) |
| 2022-10-05 07:22:38 +0200 | <Infinite> | How do I add a shared library in cabal file to do the equivalent of ghc -ldice.so Main.hs |
| 2022-10-05 07:26:41 +0200 | <jackdk> | extra-libraries: https://cabal.readthedocs.io/en/latest/cabal-package.html#pkg-field-extra-libraries |
| 2022-10-05 07:26:46 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-05 07:27:09 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-10-05 07:27:25 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-10-05 07:27:52 +0200 | andreabedini | (~andreabed@8s8kj681vht2qj3xkwc5.ip6.superloop.com) |
| 2022-10-05 07:29:03 +0200 | drlkf | (~drlkf@chat.drlkf.net) |
| 2022-10-05 07:30:03 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-10-05 07:31:13 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-05 07:32:29 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 268 seconds) |
| 2022-10-05 07:33:04 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 258 seconds) |
| 2022-10-05 07:35:59 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-10-05 07:37:47 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-05 07:41:15 +0200 | <Infinite> | I'm able to build using ghc-options flag with a hardcoded path to the .so file. It doesn't work with the extra-libraries key |
| 2022-10-05 07:41:57 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 252 seconds) |
| 2022-10-05 07:42:23 +0200 | <Infinite> | Sorry, it's fixed. Needed to add absolute path. |
| 2022-10-05 07:43:39 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-05 07:44:33 +0200 | coot | (~coot@213.134.171.3) |
| 2022-10-05 07:47:54 +0200 | twb | (~twb@2403:5804:c6::add) (rcirc on GNU Emacs 28.1) |
| 2022-10-05 07:51:07 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 252 seconds) |
| 2022-10-05 07:54:04 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-05 07:55:54 +0200 | fjMSX | (~hypni2p@2.92.213.55) |
| 2022-10-05 07:56:08 +0200 | AlexZenon_2 | (~alzenon@94.233.240.222) |
| 2022-10-05 07:56:14 +0200 | Infinite | (~Infinite@106.51.13.146) (Quit: Client closed) |
| 2022-10-05 07:57:43 +0200 | AlexZenon | (~alzenon@94.233.240.222) (Ping timeout: 252 seconds) |
| 2022-10-05 08:00:49 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-05 08:04:12 +0200 | shriekingnoise | (~shrieking@186.137.167.202) (Quit: Quit) |
| 2022-10-05 08:05:36 +0200 | kenran | (~user@user/kenran) |
| 2022-10-05 08:05:55 +0200 | Typedfern | (~Typedfern@216.red-83-37-34.dynamicip.rima-tde.net) (Read error: Connection reset by peer) |
| 2022-10-05 08:06:55 +0200 | zeenk | (~zeenk@2a02:2f04:a20a:3e00:5712:52b0:ca1d:bc63) |
| 2022-10-05 08:07:44 +0200 | Typedfern | (~Typedfern@216.red-83-37-34.dynamicip.rima-tde.net) |
| 2022-10-05 08:16:18 +0200 | Typedfern | (~Typedfern@216.red-83-37-34.dynamicip.rima-tde.net) (Remote host closed the connection) |
| 2022-10-05 08:16:21 +0200 | gmg | (~user@user/gehmehgeh) |
| 2022-10-05 08:17:35 +0200 | Typedfern | (~Typedfern@216.red-83-37-34.dynamicip.rima-tde.net) |
| 2022-10-05 08:17:55 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-05 08:18:43 +0200 | mastarija | (~mastarija@2a05:4f46:e03:6000:7d30:7520:23f1:4838) |
| 2022-10-05 08:28:37 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-10-05 08:30:29 +0200 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-10-05 08:32:37 +0200 | talismanick | (~talismani@2601:200:c100:c9e0::24ac) (Ping timeout: 246 seconds) |
| 2022-10-05 08:35:01 +0200 | goig | (~goig@202.91.42.7) |
| 2022-10-05 08:35:23 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-05 08:37:49 +0200 | jargon | (~jargon@174-22-201-96.phnx.qwest.net) (Remote host closed the connection) |
| 2022-10-05 08:41:14 +0200 | ccapndave | (~ccapndave@xcpe-62-167-164-44.cgn.res.adslplus.ch) |
| 2022-10-05 08:47:49 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 258 seconds) |
| 2022-10-05 08:48:16 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-05 08:48:36 +0200 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt juan@acm.org) |
| 2022-10-05 08:49:01 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-10-05 08:49:36 +0200 | <goig> | Basically. Both `\mu` and `\eta` take in an object and put out an object. However, in their definition they include the exact object. |
| 2022-10-05 08:49:37 +0200 | <goig> | Thus, if we assume M to be 1 and I to be 0 (illustrative purposes only) |
| 2022-10-05 08:49:37 +0200 | <goig> | `\mu`(a b) = 1 |
| 2022-10-05 08:49:38 +0200 | <goig> | `\eta`(c) = 1 |
| 2022-10-05 08:49:38 +0200 | <goig> | We can only pass 1 1 to \mu, and only 0 to \eta.Thus they make no sense. |
| 2022-10-05 08:49:55 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 08:50:05 +0200 | <goig> | This ofc is the same for everything, not just numbers. \eta just gives you the endofunctor M for the identity endofunctor. \mu just gives you the endofunctor M |
| 2022-10-05 08:50:06 +0200 | <goig> | (For the monoids in the monoidal category of endofunctors with functor composition as product, aka monads) |
| 2022-10-05 08:50:21 +0200 | <Axman6> | what is going on... |
| 2022-10-05 08:52:23 +0200 | <goig> | wat was their name cant recall properly.. you perhaps? dminuoso |
| 2022-10-05 08:54:28 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 268 seconds) |
| 2022-10-05 08:55:15 +0200 | mncheck | (~mncheck@193.224.205.254) |
| 2022-10-05 08:55:36 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-10-05 08:56:06 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-10-05 08:56:21 +0200 | chomwitt | (~chomwitt@2a02:587:dc14:f500:668b:b8eb:ac49:50a6) (Ping timeout: 268 seconds) |
| 2022-10-05 09:04:11 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:8898:dd29:29bf:fbd8) |
| 2022-10-05 09:05:00 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-05 09:10:35 +0200 | king_gs | (~Thunderbi@2806:103e:29:5a6:d0be:f9c4:80c9:e8c5) |
| 2022-10-05 09:10:49 +0200 | king_gs | (~Thunderbi@2806:103e:29:5a6:d0be:f9c4:80c9:e8c5) (Client Quit) |
| 2022-10-05 09:13:08 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a8379ab296f9eafb66f.dip0.t-ipconnect.de) |
| 2022-10-05 09:13:25 +0200 | dsrt^ | (~dsrt@c-76-17-6-165.hsd1.ga.comcast.net) |
| 2022-10-05 09:17:15 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 09:20:05 +0200 | michalz | (~michalz@185.246.207.203) |
| 2022-10-05 09:21:33 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 258 seconds) |
| 2022-10-05 09:21:41 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 252 seconds) |
| 2022-10-05 09:21:45 +0200 | chomwitt | (~chomwitt@2a02:587:dc14:f500:a36a:c8e2:2dbf:bfd5) |
| 2022-10-05 09:22:06 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-10-05 09:24:27 +0200 | chomwitt | (~chomwitt@2a02:587:dc14:f500:a36a:c8e2:2dbf:bfd5) (Remote host closed the connection) |
| 2022-10-05 09:24:44 +0200 | chomwitt | (~chomwitt@2a02:587:dc14:f500:d53b:b7dd:b89c:482e) |
| 2022-10-05 09:28:30 +0200 | Midjak | (~Midjak@82.66.147.146) |
| 2022-10-05 09:31:50 +0200 | CiaoSen | (~Jura@p200300c95700eb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-10-05 09:32:41 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2022-10-05 09:33:25 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-05 09:38:29 +0200 | CiaoSen | (~Jura@p200300c95700eb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Quit: CiaoSen) |
| 2022-10-05 09:48:05 +0200 | m5zs7k | (aquares@web10.mydevil.net) (Ping timeout: 252 seconds) |
| 2022-10-05 09:49:04 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2022-10-05 09:50:18 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 258 seconds) |
| 2022-10-05 09:51:14 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 09:52:39 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-10-05 09:53:11 +0200 | m5zs7k | (aquares@web10.mydevil.net) |
| 2022-10-05 09:53:47 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 250 seconds) |
| 2022-10-05 09:57:34 +0200 | ccapndave | (~ccapndave@xcpe-62-167-164-44.cgn.res.adslplus.ch) (Quit: Textual IRC Client: www.textualapp.com) |
| 2022-10-05 09:58:19 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2022-10-05 10:04:53 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-10-05 10:05:43 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-10-05 10:05:46 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-10-05 10:06:43 +0200 | kdaishi | (~Thunderbi@dyn3135-159.wlan.ic.ac.uk) |
| 2022-10-05 10:10:41 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 265 seconds) |
| 2022-10-05 10:11:09 +0200 | __monty__ | (~toonn@user/toonn) |
| 2022-10-05 10:15:51 +0200 | kdaishi | (~Thunderbi@dyn3135-159.wlan.ic.ac.uk) (Ping timeout: 260 seconds) |
| 2022-10-05 10:19:36 +0200 | CiaoSen | (~Jura@p200300c95700eb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-10-05 10:21:59 +0200 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) |
| 2022-10-05 10:24:21 +0200 | mihaiadrian | (~mihaiadri@82.76.223.244) |
| 2022-10-05 10:27:01 +0200 | <mihaiadrian> | hi |
| 2022-10-05 10:27:42 +0200 | <mihaiadrian> | given the following function: https://pastebin.com/raw/gHc97b0a |
| 2022-10-05 10:27:48 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2022-10-05 10:28:14 +0200 | <mihaiadrian> | if i want to replace computeArea |
| 2022-10-05 10:28:15 +0200 | <mihaiadrian> | computeArea = (/ 2.0) . fromIntegral . trapezoidalArea |
| 2022-10-05 10:28:19 +0200 | <mihaiadrian> | i get the following error |
| 2022-10-05 10:28:42 +0200 | <mihaiadrian> | https://pastebin.com/raw/mqZzscTx |
| 2022-10-05 10:29:15 +0200 | <Hecate> | your usage of point-free style hides the fact that you're trying to divide a what seems to be a partially-applied function |
| 2022-10-05 10:29:20 +0200 | <Hecate> | and not a value |
| 2022-10-05 10:29:48 +0200 | <Hecate> | you want to operate on the Float but haven't applied to the two GridPoints that are required :) |
| 2022-10-05 10:29:52 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 10:29:53 +0200 | <Hecate> | mihaiadrian: does that make sense? |
| 2022-10-05 10:30:01 +0200 | <mihaiadrian> | hm, yes |
| 2022-10-05 10:30:21 +0200 | <Hecate> | mihaiadrian: use a very explicit style first, it's always easier to simplify to point-free later |
| 2022-10-05 10:33:16 +0200 | kuribas | (~user@ptr-17d51eoey8zgtxv1hcd.18120a2.ip6.access.telenet.be) |
| 2022-10-05 10:34:05 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 250 seconds) |
| 2022-10-05 10:34:22 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2022-10-05 10:34:30 +0200 | frost | (~frost@user/frost) |
| 2022-10-05 10:38:33 +0200 | <Axman6> | @src (.) |
| 2022-10-05 10:38:33 +0200 | <lambdabot> | (f . g) x = f (g x) |
| 2022-10-05 10:40:46 +0200 | <Axman6> | mihaiadrian: try substituting the definition of (.) into your attempt to make computeArea point-free, so (/ 2.0) . fromIntegral . trapezoidalArea => (\x -> (/ 2.0) (fromIntegral x)) . trapezoidalArea etc |
| 2022-10-05 10:41:14 +0200 | andreabedini | (~andreabed@8s8kj681vht2qj3xkwc5.ip6.superloop.com) (Quit: WeeChat 3.6) |
| 2022-10-05 10:41:24 +0200 | chele | (~chele@user/chele) |
| 2022-10-05 10:41:28 +0200 | <Axman6> | (it's a bit easier if you use the definition: f . g = \x -> f (g x) |
| 2022-10-05 10:41:30 +0200 | <Axman6> | ) |
| 2022-10-05 10:43:55 +0200 | ubert | (~Thunderbi@178.165.179.119.wireless.dyn.drei.com) |
| 2022-10-05 10:46:39 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::778c) (Ping timeout: 250 seconds) |
| 2022-10-05 10:52:01 +0200 | burnsidesLlama | (~burnsides@client-8-79.eduroam.oxuni.org.uk) |
| 2022-10-05 10:54:50 +0200 | MajorBiscuit | (~MajorBisc@145.94.167.158) |
| 2022-10-05 10:58:30 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-10-05 11:00:11 +0200 | komikat[m] | (~komikatma@2001:470:69fc:105::1:c71e) (Quit: You have been kicked for being idle) |
| 2022-10-05 11:00:22 +0200 | goig | (~goig@202.91.42.7) (Ping timeout: 252 seconds) |
| 2022-10-05 11:00:46 +0200 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) (Ping timeout: 260 seconds) |
| 2022-10-05 11:02:57 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 11:04:02 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-05 11:07:46 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 260 seconds) |
| 2022-10-05 11:10:22 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 11:11:45 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-10-05 11:12:16 +0200 | ft | (~ft@p3e9bc57b.dip0.t-ipconnect.de) (Quit: leaving) |
| 2022-10-05 11:12:22 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-05 11:12:47 +0200 | mikoto-chan | (~mikoto-ch@nat1.panoulu.net) |
| 2022-10-05 11:19:49 +0200 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) |
| 2022-10-05 11:19:54 +0200 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) |
| 2022-10-05 11:20:35 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 248 seconds) |
| 2022-10-05 11:22:27 +0200 | mikoto-chan | (~mikoto-ch@nat1.panoulu.net) (Read error: Connection reset by peer) |
| 2022-10-05 11:29:15 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:463c:6245:cbff:fe9f:48b1) |
| 2022-10-05 11:31:29 +0200 | wonko | (~wjc@2a0e:1c80:11::50) |
| 2022-10-05 11:33:10 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 11:41:19 +0200 | vorpuni | (~pvorp@2001:861:3881:c690:9a07:c8cf:2f0:185c) |
| 2022-10-05 11:49:57 +0200 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) (Quit: kdaishi) |
| 2022-10-05 11:50:11 +0200 | kdaishi | (~Thunderbi@dyn3143-57.wlan.ic.ac.uk) |
| 2022-10-05 11:51:48 +0200 | beteigeuze | (~Thunderbi@2001:8a0:61b5:6101:f0c:e4e3:bfdc:91df) |
| 2022-10-05 11:54:47 +0200 | kdaishi | (~Thunderbi@dyn3143-57.wlan.ic.ac.uk) (Client Quit) |
| 2022-10-05 11:55:04 +0200 | kdaishi | (~Thunderbi@dyn3143-57.wlan.ic.ac.uk) |
| 2022-10-05 11:58:51 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-10-05 11:58:57 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) |
| 2022-10-05 12:02:24 +0200 | vglfr | (~vglfr@145.224.100.190) (Remote host closed the connection) |
| 2022-10-05 12:02:31 +0200 | fjMSX | (~hypni2p@2.92.213.55) (Remote host closed the connection) |
| 2022-10-05 12:03:08 +0200 | vglfr | (~vglfr@145.224.100.190) |
| 2022-10-05 12:03:46 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Ping timeout: 260 seconds) |
| 2022-10-05 12:04:17 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-10-05 12:05:48 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a8379ab296f9eafb66f.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2022-10-05 12:05:56 +0200 | carlosming | (~carlosmin@182.1.91.10) |
| 2022-10-05 12:06:14 +0200 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-10-05 12:08:15 +0200 | kuribas | (~user@ptr-17d51eoey8zgtxv1hcd.18120a2.ip6.access.telenet.be) (Ping timeout: 268 seconds) |
| 2022-10-05 12:08:44 +0200 | vorpuni | (~pvorp@2001:861:3881:c690:9a07:c8cf:2f0:185c) (Quit: bye) |
| 2022-10-05 12:11:08 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-05 12:12:22 +0200 | vorpuni | (~pvorp@2001:861:3881:c690:5407:9f9e:afb1:b17e) |
| 2022-10-05 12:17:32 +0200 | carlosming | (~carlosmin@182.1.91.10) (Quit: On my way jerking to /r/programmingcirclejerk) |
| 2022-10-05 12:18:05 +0200 | talismanick | (~talismani@2601:200:c100:c9e0::24ac) |
| 2022-10-05 12:23:55 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 12:25:10 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 258 seconds) |
| 2022-10-05 12:25:57 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:463c:6245:cbff:fe9f:48b1) (Quit: Leaving) |
| 2022-10-05 12:26:51 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 252 seconds) |
| 2022-10-05 12:34:31 +0200 | fef | (~thedawn@user/thedawn) |
| 2022-10-05 12:36:21 +0200 | vglfr | (~vglfr@145.224.100.190) (Read error: Connection reset by peer) |
| 2022-10-05 12:37:14 +0200 | vglfr | (~vglfr@145.224.100.190) |
| 2022-10-05 12:38:34 +0200 | zaquest | (~notzaques@5.130.79.72) |
| 2022-10-05 12:42:51 +0200 | Unode | (~Unode@194.94.44.220) (Ping timeout: 260 seconds) |
| 2022-10-05 12:44:43 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 258 seconds) |
| 2022-10-05 12:45:56 +0200 | kenran | (~user@user/kenran) |
| 2022-10-05 12:48:09 +0200 | `2jt | (~jtomas@90.red-88-17-81.dynamicip.rima-tde.net) |
| 2022-10-05 12:50:17 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a8379ab296f9eafb66f.dip0.t-ipconnect.de) |
| 2022-10-05 12:58:07 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds) |
| 2022-10-05 13:00:41 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2022-10-05 13:01:43 +0200 | Unode | (~Unode@194.94.44.220) |
| 2022-10-05 13:16:33 +0200 | burnsidesLlama | (~burnsides@client-8-79.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2022-10-05 13:17:43 +0200 | potash | (~foghorn@user/foghorn) (Excess Flood) |
| 2022-10-05 13:17:59 +0200 | potash | (~foghorn@user/foghorn) |
| 2022-10-05 13:18:59 +0200 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) |
| 2022-10-05 13:19:36 +0200 | fef | (~thedawn@user/thedawn) (Ping timeout: 258 seconds) |
| 2022-10-05 13:19:36 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) (Ping timeout: 264 seconds) |
| 2022-10-05 13:23:53 +0200 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-10-05 13:28:05 +0200 | zaquest | (~notzaques@5.130.79.72) |
| 2022-10-05 13:31:59 +0200 | fef | (~thedawn@user/thedawn) |
| 2022-10-05 13:32:05 +0200 | fef | (~thedawn@user/thedawn) (Remote host closed the connection) |
| 2022-10-05 13:32:05 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 13:32:40 +0200 | fef | (~thedawn@user/thedawn) |
| 2022-10-05 13:33:38 +0200 | frost | (~frost@user/frost) (Quit: Client closed) |
| 2022-10-05 13:33:51 +0200 | mastarija | (~mastarija@2a05:4f46:e03:6000:7d30:7520:23f1:4838) (Ping timeout: 268 seconds) |
| 2022-10-05 13:34:00 +0200 | frost | (~frost@user/frost) |
| 2022-10-05 13:36:54 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 268 seconds) |
| 2022-10-05 13:39:23 +0200 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) |
| 2022-10-05 13:46:47 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-10-05 13:47:05 +0200 | mihaiadrian | (~mihaiadri@82.76.223.244) (Quit: Client closed) |
| 2022-10-05 13:47:13 +0200 | nschoe | (~quassel@141.101.51.197) |
| 2022-10-05 13:49:22 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-10-05 13:50:28 +0200 | kevinsjoberg | (sid499516@id-499516.lymington.irccloud.com) () |
| 2022-10-05 13:55:20 +0200 | wonko | (~wjc@2a0e:1c80:11::50) (Ping timeout: 268 seconds) |
| 2022-10-05 14:00:13 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 14:00:33 +0200 | luffy | (~chenqisu1@183.217.200.18) |
| 2022-10-05 14:00:53 +0200 | lyle | (~lyle@104.246.145.85) |
| 2022-10-05 14:03:43 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 246 seconds) |
| 2022-10-05 14:07:12 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-10-05 14:07:26 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 260 seconds) |
| 2022-10-05 14:08:20 +0200 | vorpuni | (~pvorp@2001:861:3881:c690:5407:9f9e:afb1:b17e) (Quit: bye) |
| 2022-10-05 14:10:29 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-10-05 14:11:12 +0200 | mihaiadrian | (~mihaiadri@82.76.223.244) |
| 2022-10-05 14:12:37 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 268 seconds) |
| 2022-10-05 14:15:04 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-05 14:15:04 +0200 | lambdap237 | (~lambdap@static.167.190.119.168.clients.your-server.de) (Quit: Ping timeout (120 seconds)) |
| 2022-10-05 14:18:17 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 14:19:31 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-10-05 14:22:26 +0200 | fef | (~thedawn@user/thedawn) (Leaving) |
| 2022-10-05 14:22:59 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 265 seconds) |
| 2022-10-05 14:27:34 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 14:32:37 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 252 seconds) |
| 2022-10-05 14:37:32 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2022-10-05 14:38:33 +0200 | gmg | (~user@user/gehmehgeh) |
| 2022-10-05 14:41:22 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 14:43:22 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) |
| 2022-10-05 14:44:02 +0200 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-10-05 14:44:38 +0200 | luffy | (~chenqisu1@183.217.200.18) (Remote host closed the connection) |
| 2022-10-05 14:44:49 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 14:46:30 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-10-05 14:49:44 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 268 seconds) |
| 2022-10-05 14:50:17 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-05 15:00:48 +0200 | kdaishi | (~Thunderbi@dyn3143-57.wlan.ic.ac.uk) (Ping timeout: 268 seconds) |
| 2022-10-05 15:03:22 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 15:03:50 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 15:04:19 +0200 | AlexZenon_2 | AlexZenon |
| 2022-10-05 15:06:29 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 265 seconds) |
| 2022-10-05 15:08:51 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 248 seconds) |
| 2022-10-05 15:09:16 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 260 seconds) |
| 2022-10-05 15:10:26 +0200 | vglfr | (~vglfr@145.224.100.190) (Ping timeout: 260 seconds) |
| 2022-10-05 15:10:27 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a8379ab296f9eafb66f.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2022-10-05 15:10:48 +0200 | frost | (~frost@user/frost) (Ping timeout: 252 seconds) |
| 2022-10-05 15:10:59 +0200 | jero98772 | (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) |
| 2022-10-05 15:13:42 +0200 | <ski> | computeArea = (((/ 2.0) . fromIntegral .) .) . trapezoidalArea -- mihaiadrian, the correct pointless |
| 2022-10-05 15:15:22 +0200 | <chreekat> | pointlessly correct! |
| 2022-10-05 15:16:43 +0200 | ski | nods |
| 2022-10-05 15:17:54 +0200 | <chreekat> | :) |
| 2022-10-05 15:20:15 +0200 | <mihaiadrian> | thanks ski |
| 2022-10-05 15:21:24 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 15:22:04 +0200 | draz | (~aorti@89.40.74.126) |
| 2022-10-05 15:25:14 +0200 | vglfr | (~vglfr@145.224.100.190) |
| 2022-10-05 15:26:19 +0200 | <ski> | it would be possible to reformulate it as |
| 2022-10-05 15:27:21 +0200 | <ski> | computeArea = ((/ 2.0) . fromIntegral) .:: trapezoidalArea |
| 2022-10-05 15:27:24 +0200 | <ski> | if you define |
| 2022-10-05 15:27:27 +0200 | frost | (~frost@user/frost) |
| 2022-10-05 15:27:32 +0200 | <ski> | infixr 9 .:: |
| 2022-10-05 15:27:51 +0200 | <ski> | (.::) :: (c0 -> c1) -> (a -> b -> c0) -> (a -> b -> c1) |
| 2022-10-05 15:28:01 +0200 | <ski> | (.::) = (.) . (.) . (.) |
| 2022-10-05 15:28:29 +0200 | <ski> | (f .:: g) x y z = f (g x y z) -- which is the same as this |
| 2022-10-05 15:28:41 +0200 | <ski> | oh, sorry, the signature should be |
| 2022-10-05 15:28:43 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 252 seconds) |
| 2022-10-05 15:28:58 +0200 | <ski> | (.:::) :: (d0 -> d1) -> (a -> b -> c -> d0) -> (a -> b -> c -> d1) |
| 2022-10-05 15:29:14 +0200 | ski | sighs |
| 2022-10-05 15:30:31 +0200 | notzmv | (~zmv@user/notzmv) (Ping timeout: 246 seconds) |
| 2022-10-05 15:32:47 +0200 | mihaiadrian | (~mihaiadri@82.76.223.244) (Quit: Client closed) |
| 2022-10-05 15:34:16 +0200 | frost | (~frost@user/frost) (Ping timeout: 252 seconds) |
| 2022-10-05 15:42:05 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 15:46:36 +0200 | erisco | (~erisco@d24-57-249-233.home.cgocable.net) (Ping timeout: 260 seconds) |
| 2022-10-05 15:47:16 +0200 | razetime | (~quassel@117.193.2.107) |
| 2022-10-05 15:47:47 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-05 15:48:34 +0200 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) |
| 2022-10-05 15:49:00 +0200 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) (Ping timeout: 264 seconds) |
| 2022-10-05 15:50:00 +0200 | mastarija | (~mastarija@2a05:4f46:e03:6000:7427:e421:29b4:3f4e) |
| 2022-10-05 15:50:43 +0200 | draz | (~aorti@89.40.74.126) (Quit: Konversation terminated!) |
| 2022-10-05 15:51:12 +0200 | erisco | (~erisco@d24-57-249-233.home.cgocable.net) |
| 2022-10-05 15:52:10 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 15:52:30 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-10-05 15:52:30 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-10-05 15:52:30 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-10-05 15:54:20 +0200 | zebrag | (~chris@user/zebrag) |
| 2022-10-05 15:56:48 +0200 | son0p | (~ff@181.136.122.143) (Ping timeout: 264 seconds) |
| 2022-10-05 15:57:00 +0200 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) (Quit: Leaving.) |
| 2022-10-05 15:58:07 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 268 seconds) |
| 2022-10-05 15:59:10 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 265 seconds) |
| 2022-10-05 16:02:10 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Quit: WeeChat 3.6) |
| 2022-10-05 16:02:13 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-10-05 16:02:14 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 16:02:37 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) |
| 2022-10-05 16:03:28 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 16:03:45 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-10-05 16:04:14 +0200 | nightbreak | (~nightbrea@2600:4040:5416:c000:89ef:7927:9e8f:36c6) |
| 2022-10-05 16:05:04 +0200 | kdaishi | (~Thunderbi@94.191.153.178) |
| 2022-10-05 16:06:55 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Ping timeout: 246 seconds) |
| 2022-10-05 16:07:37 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 246 seconds) |
| 2022-10-05 16:07:52 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-05 16:10:31 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 260 seconds) |
| 2022-10-05 16:12:20 +0200 | nightbreak | nightbreak[Away] |
| 2022-10-05 16:15:24 +0200 | `2jt | (~jtomas@90.red-88-17-81.dynamicip.rima-tde.net) (Ping timeout: 264 seconds) |
| 2022-10-05 16:18:51 +0200 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) |
| 2022-10-05 16:20:23 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 16:22:13 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 16:22:27 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 258 seconds) |
| 2022-10-05 16:24:18 +0200 | nschoe | (~quassel@141.101.51.197) (Ping timeout: 265 seconds) |
| 2022-10-05 16:24:21 +0200 | nschoe_ | (~quassel@141.101.51.197) |
| 2022-10-05 16:25:37 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-10-05 16:25:54 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-05 16:26:39 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 252 seconds) |
| 2022-10-05 16:30:28 +0200 | silky[m] | (~noonvande@2001:470:69fc:105::2:943c) |
| 2022-10-05 16:34:09 +0200 | zer0bitz | (~zer0bitz@2001:2003:f748:2000:8816:b288:20c9:6a7a) |
| 2022-10-05 16:34:54 +0200 | mncheck | (~mncheck@193.224.205.254) (Read error: Connection reset by peer) |
| 2022-10-05 16:36:12 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 16:39:58 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::778c) |
| 2022-10-05 16:40:50 +0200 | mihaiadrian | (~mihaiadri@82.76.223.244) |
| 2022-10-05 16:41:10 +0200 | <mihaiadrian> | ski, Axman6, Hecate: thank you all! sorry for responding so late. |
| 2022-10-05 16:41:12 +0200 | causal | (~user@50.35.83.177) (Quit: WeeChat 3.6) |
| 2022-10-05 16:41:33 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 250 seconds) |
| 2022-10-05 16:41:44 +0200 | <Hecate> | nae worries |
| 2022-10-05 16:44:13 +0200 | loras | (~bc@c-73-139-125-125.hsd1.fl.comcast.net) |
| 2022-10-05 16:44:35 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 16:46:26 +0200 | nschoe_ | (~quassel@141.101.51.197) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-10-05 16:46:40 +0200 | nschoe | (~quassel@141.101.51.197) |
| 2022-10-05 16:53:02 +0200 | <silky[m]> | <Hecate> "nae worries" <- are you scottish?! |
| 2022-10-05 16:55:14 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-05 16:55:35 +0200 | littlefinger | (~littlefin@pool-100-15-237-121.washdc.fios.verizon.net) |
| 2022-10-05 16:58:11 +0200 | mihaiadrian | (~mihaiadri@82.76.223.244) (Quit: Client closed) |
| 2022-10-05 16:58:47 +0200 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) |
| 2022-10-05 16:59:48 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 17:08:05 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 252 seconds) |
| 2022-10-05 17:09:50 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2022-10-05 17:10:35 +0200 | <Hecate> | silky[m]: no and you know it :') |
| 2022-10-05 17:10:56 +0200 | <EvanR> | so if you have a state record where one field is supposed to be a list that you incrementally append to |
| 2022-10-05 17:11:44 +0200 | <EvanR> | I know two ways: build the list backwards then reverse it, or use "prefix function" and compose them instead of using a list |
| 2022-10-05 17:12:29 +0200 | <EvanR> | 1. is there another way 2. is there any benefit here of using the function composition approach |
| 2022-10-05 17:13:23 +0200 | <EvanR> | maybe Data.Sequence? |
| 2022-10-05 17:13:26 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-05 17:13:42 +0200 | <lortabac> | EvanR: DList |
| 2022-10-05 17:13:59 +0200 | <EvanR> | that's the same thing as function composition I mentioned |
| 2022-10-05 17:14:02 +0200 | <lortabac> | yes |
| 2022-10-05 17:14:14 +0200 | <lortabac> | but it's wrapped in a newtype |
| 2022-10-05 17:14:41 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 17:14:43 +0200 | <lortabac> | Data.Sequence may be useful if you need indexing |
| 2022-10-05 17:14:53 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2022-10-05 17:15:24 +0200 | littlefinger | (~littlefin@pool-100-15-237-121.washdc.fios.verizon.net) (Quit: Client closed) |
| 2022-10-05 17:15:30 +0200 | <lortabac> | otherwise I think DList is the best way to build the list |
| 2022-10-05 17:15:52 +0200 | <EvanR> | is there any benefit over just using the list |
| 2022-10-05 17:16:02 +0200 | <EvanR> | for that particular problem |
| 2022-10-05 17:16:17 +0200 | <lortabac> | benefit of Data.Sequence? |
| 2022-10-05 17:16:28 +0200 | littlefinger | (~littlefin@pool-100-15-237-121.washdc.fios.verizon.net) |
| 2022-10-05 17:16:32 +0200 | <lortabac> | I don't think so (if it's just for incremental building) |
| 2022-10-05 17:16:36 +0200 | <EvanR> | DList |
| 2022-10-05 17:16:54 +0200 | <lortabac> | DList compared to what? |
| 2022-10-05 17:16:57 +0200 | <EvanR> | ok! |
| 2022-10-05 17:17:15 +0200 | <EvanR> | not addressing my original question lol |
| 2022-10-05 17:17:23 +0200 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) |
| 2022-10-05 17:18:03 +0200 | <lortabac> | sorry maybe I misunderstood the question then |
| 2022-10-05 17:20:05 +0200 | <EvanR> | there are two main ways to implement the append within the context of this state thing, build the list backwards reverse it at the end, and compose prefixing functions. DList isn't another fundamentally different way yes I know about it. Is there any benefit other than cool factor to not just use a dumb list |
| 2022-10-05 17:22:00 +0200 | <EvanR> | because a dumb list is less code, it has that going for it |
| 2022-10-05 17:22:49 +0200 | <lortabac> | probably with a reversed list you depend on compiler optimizations, whereas function composition is always efficient |
| 2022-10-05 17:24:20 +0200 | <[Leary]> | DList (or other function embeddings like foldr lists) will be the fastest if you only consume the list once. Something that builds a real data structure may be faster if you need to consume the list several times, as you can leverage sharing. Note the `SnocBuilder` data type (internal to Data.List) and related comments. |
| 2022-10-05 17:24:48 +0200 | dsrt^ | (~dsrt@c-76-17-6-165.hsd1.ga.comcast.net) (Remote host closed the connection) |
| 2022-10-05 17:25:03 +0200 | <EvanR> | checking that out |
| 2022-10-05 17:29:42 +0200 | `2jt | (~jtomas@90.red-88-17-81.dynamicip.rima-tde.net) |
| 2022-10-05 17:32:02 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-10-05 17:33:06 +0200 | littlefinger | (~littlefin@pool-100-15-237-121.washdc.fios.verizon.net) (Quit: Client closed) |
| 2022-10-05 17:33:57 +0200 | <EvanR> | SnocBuilder seems to be like a dumb backwards list but you spread the reversing work out instead of waiting until the end |
| 2022-10-05 17:35:21 +0200 | <EvanR> | it's doubling down on reversing xD |
| 2022-10-05 17:35:22 +0200 | <lortabac> | why wouldn't a list built with function composition be shared? |
| 2022-10-05 17:36:03 +0200 | <lortabac> | I mean, if you do 'let list = DList.toList dlist' isn't 'list' shared? |
| 2022-10-05 17:36:57 +0200 | <lortabac> | I don't understand how the way the list is built changes anything regarding sharing |
| 2022-10-05 17:38:22 +0200 | <EvanR> | if you only consume the final list once, no nothing is shared and you might never even have the list in memory really |
| 2022-10-05 17:38:42 +0200 | mixphix | (~cigsender@cpe9050ca1782b3-cm9050ca1782b0.sdns.net.rogers.com) |
| 2022-10-05 17:38:49 +0200 | <EvanR> | during construction there's no sharing since there's no list yet |
| 2022-10-05 17:39:49 +0200 | <[Leary]> | My wording was imprecise; the issue is that you can't benefit from sharing when consuming the function-list at distinct stages of its construction. |
| 2022-10-05 17:39:49 +0200 | <EvanR> | the comments mention "heavily persistent settings", which I take to mean you want the data materialized and reused as much as possible over time |
| 2022-10-05 17:40:32 +0200 | <[Leary]> | The list is in state; you might want to modify it, consume it, modify it, consume it again, etc. |
| 2022-10-05 17:40:46 +0200 | <lortabac> | ok I see what you mean |
| 2022-10-05 17:40:48 +0200 | <[Leary]> | You'll have to rebuild the list completely to do so. |
| 2022-10-05 17:41:35 +0200 | <lortabac> | in that case something like Data.Sequence would definitely make sense |
| 2022-10-05 17:41:35 +0200 | <EvanR> | yeah if you want to do various things other than just append one item to the end, I can see DList being better |
| 2022-10-05 17:41:52 +0200 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq) |
| 2022-10-05 17:41:54 +0200 | <EvanR> | or Sequence depending |
| 2022-10-05 17:42:12 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:8898:dd29:29bf:fbd8) (Quit: WeeChat 2.8) |
| 2022-10-05 17:42:40 +0200 | waleee | (~waleee@192.165.44.49) |
| 2022-10-05 17:43:15 +0200 | <EvanR> | SnocBuilder appears to have been removed from Data.List in the meantime |
| 2022-10-05 17:43:17 +0200 | `2jt | (~jtomas@90.red-88-17-81.dynamicip.rima-tde.net) (Ping timeout: 252 seconds) |
| 2022-10-05 17:43:39 +0200 | euandreh | (~euandreh@179.214.113.107) (Ping timeout: 252 seconds) |
| 2022-10-05 17:45:22 +0200 | <[Leary]> | Oh yeah, looks like 4.17 has it in Data.OldList. I was looking as 4.16. |
| 2022-10-05 17:45:49 +0200 | euandreh | (~euandreh@179.214.113.107) |
| 2022-10-05 17:45:56 +0200 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-10-05 17:46:02 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-05 17:46:22 +0200 | <EvanR> | SnocList is interesting on the surface because it goes to some effort to make sure your backwards doesn't get too long |
| 2022-10-05 17:46:23 +0200 | finsternis | (~X@23.226.237.192) (Read error: Connection reset by peer) |
| 2022-10-05 17:46:33 +0200 | <EvanR> | backwards list |
| 2022-10-05 17:47:15 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) |
| 2022-10-05 17:48:13 +0200 | finsternis | (~X@23.226.237.192) |
| 2022-10-05 17:50:49 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 265 seconds) |
| 2022-10-05 18:01:15 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2022-10-05 18:03:27 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 252 seconds) |
| 2022-10-05 18:04:23 +0200 | mastarija | (~mastarija@2a05:4f46:e03:6000:7427:e421:29b4:3f4e) (Quit: WeeChat 3.5) |
| 2022-10-05 18:04:38 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 18:08:25 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Remote host closed the connection) |
| 2022-10-05 18:08:43 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-10-05 18:08:56 +0200 | son0p | (~ff@181.136.122.143) |
| 2022-10-05 18:09:10 +0200 | nschoe | (~quassel@141.101.51.197) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-10-05 18:11:52 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 246 seconds) |
| 2022-10-05 18:13:39 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 18:13:49 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 268 seconds) |
| 2022-10-05 18:18:39 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-05 18:29:55 +0200 | Erez | (~Erez@155.4.187.85) |
| 2022-10-05 18:32:23 +0200 | econo | (uid147250@user/econo) |
| 2022-10-05 18:39:41 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-05 18:45:15 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 252 seconds) |
| 2022-10-05 18:45:26 +0200 | euandreh | (~euandreh@179.214.113.107) (Ping timeout: 265 seconds) |
| 2022-10-05 18:50:07 +0200 | euandreh | (~euandreh@179.214.113.107) |
| 2022-10-05 18:54:08 +0200 | MajorBiscuit | (~MajorBisc@145.94.167.158) (Ping timeout: 265 seconds) |
| 2022-10-05 18:54:25 +0200 | Erez | (~Erez@155.4.187.85) (Remote host closed the connection) |
| 2022-10-05 18:54:42 +0200 | Erez | (~Erez@h-155-4-187-85.A980.priv.bahnhof.se) |
| 2022-10-05 18:55:47 +0200 | <dminuoso> | Is there an known efficient construction for a tree, in which each node is indexed say by an Int, such that [Int] represents a path along that tree? Currently Im using a recursive IntMap construction, but that's not particularly efficient to construct, because I have to alterF every IntMap along the way for each inserted node. |
| 2022-10-05 18:56:28 +0200 | <dminuoso> | A variant Ive been pondering is to wrap each layer in an IORef, such that an insertion is rather just a lookup and then alter of the merge node |
| 2022-10-05 18:56:37 +0200 | <dminuoso> | But Ive been wondering about some pure functional construction |
| 2022-10-05 18:57:13 +0200 | goig | (~goig@202.91.42.7) |
| 2022-10-05 18:58:46 +0200 | <goig> | dminuoso you there bud? |
| 2022-10-05 18:59:10 +0200 | king_gs | (~Thunderbi@2806:103e:29:5a6:d0be:f9c4:80c9:e8c5) |
| 2022-10-05 18:59:10 +0200 | king_gs | (~Thunderbi@2806:103e:29:5a6:d0be:f9c4:80c9:e8c5) (Client Quit) |
| 2022-10-05 18:59:14 +0200 | <dminuoso> | goig: Yes. |
| 2022-10-05 18:59:25 +0200 | waleee | (~waleee@192.165.44.49) (Ping timeout: 268 seconds) |
| 2022-10-05 19:00:28 +0200 | <goig> | dminuoso |
| 2022-10-05 19:00:41 +0200 | <goig> | Basically. Both \mu and \eta take in an object and put out an object. However, in their definition they include the exact object. Thus, if we assume M to be 1 and I to be 0 (illustrative purposes only) |
| 2022-10-05 19:00:41 +0200 | <goig> | \mu(a b) = 1 |
| 2022-10-05 19:00:42 +0200 | <goig> | \eta(c) = 1 |
| 2022-10-05 19:00:42 +0200 | <goig> | We can only pass 1 1 to \mu, and only 0 to \eta. Thus they make no sense. |
| 2022-10-05 19:00:58 +0200 | <goig> | This ofc is the same for everything, not just numbers. \eta just gives you the endofunctor M for the identity endofunctor. \mu just gives you the endofunctor M |
| 2022-10-05 19:00:59 +0200 | <goig> | (For the monoids in the monoidal category of endofunctors with functor composition as product, aka monads) |
| 2022-10-05 19:01:29 +0200 | <dminuoso> | goig: μ and η are first, for the matter of this discussion, natural transformations. |
| 2022-10-05 19:01:43 +0200 | <dminuoso> | Do you know what a natural transformation is? |
| 2022-10-05 19:02:01 +0200 | <ski> | goig : "we assume M to be 1 and I to be 0" -- what do you mean by `1' and `0' here ? |
| 2022-10-05 19:02:24 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2022-10-05 19:02:40 +0200 | <goig> | dminuoso Wait. But wikipedia defines them as morphisms... |
| 2022-10-05 19:02:50 +0200 | <c_wraith> | dminuoso: If the Int are dense, you can't really do better. |
| 2022-10-05 19:02:52 +0200 | <dminuoso> | goig: Well yes, they are morphisms in a category. |
| 2022-10-05 19:03:02 +0200 | <c_wraith> | dminuoso: err. if they aren't dense |
| 2022-10-05 19:03:04 +0200 | <goig> | Do you know what a natural transformation is? Mapping between functors |
| 2022-10-05 19:03:06 +0200 | <dminuoso> | Our category is the category of endofunctors, in which objects are endofunctors, and morphisms between endofunctors are natural transformations. |
| 2022-10-05 19:03:31 +0200 | <dminuoso> | So in that category, every morphism is a natural transformation. |
| 2022-10-05 19:04:39 +0200 | <goig> | Ooo |
| 2022-10-05 19:05:01 +0200 | <dminuoso> | There's a bit of inception here of course. |
| 2022-10-05 19:05:38 +0200 | <goig> | Still, my question hold.. |
| 2022-10-05 19:05:51 +0200 | <goig> | \infty-Category /s |
| 2022-10-05 19:05:56 +0200 | <goig> | A natural transformation is still a transformation/morphism |
| 2022-10-05 19:06:17 +0200 | <EvanR> | category theory is the study of patterns/interfaces which are optimized for talking about its own damn self |
| 2022-10-05 19:06:34 +0200 | <dminuoso> | Even the study of itself. :) |
| 2022-10-05 19:06:34 +0200 | kdaishi | (~Thunderbi@94.191.153.178) (Read error: Connection reset by peer) |
| 2022-10-05 19:06:34 +0200 | <goig> | If we define the morphism as giving us a defined endofunctor included in is definition |
| 2022-10-05 19:06:34 +0200 | <goig> | It's the same case as with the numbers |
| 2022-10-05 19:06:45 +0200 | <dminuoso> | What do you mean "we define the morphism"? |
| 2022-10-05 19:06:48 +0200 | <dminuoso> | We dont define morphisms. |
| 2022-10-05 19:06:51 +0200 | <dminuoso> | They simply exist. |
| 2022-10-05 19:07:00 +0200 | <EvanR> | that's not very constructive |
| 2022-10-05 19:07:35 +0200 | <goig> | well. What is the wikipedia article saying then? |
| 2022-10-05 19:07:48 +0200 | <dminuoso> | Can you give me a link to the article, and a pointer where you are looking at? |
| 2022-10-05 19:07:50 +0200 | <ski> | goig : "\eta just gives you the endofunctor M for the identity endofunctor. \mu just gives you the endofunctor M" makes no sense to me |
| 2022-10-05 19:09:07 +0200 | <goig> | dminuoso https://en.wikipedia.org/wiki/Monoid_(category_theory) |
| 2022-10-05 19:10:07 +0200 | <ski> | goig : what do you mean by `\eta(c) = 1',`\mu(a b) = 1' ? |
| 2022-10-05 19:11:11 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 19:11:34 +0200 | <sm> | g'day all. A slight mystery.. does nub require first sorting the list to be reliable ? I thought so, but today it seems unnecessary |
| 2022-10-05 19:12:00 +0200 | <ski> | > nub "aba" |
| 2022-10-05 19:12:02 +0200 | <lambdabot> | "ab" |
| 2022-10-05 19:12:13 +0200 | <ski> | it compares every element to every element. it's quadratic |
| 2022-10-05 19:12:33 +0200 | <ski> | (or, "triangular", if you prefer) |
| 2022-10-05 19:12:34 +0200 | <dminuoso> | sm: You were probably thinking of `group` and friends |
| 2022-10-05 19:12:44 +0200 | <dminuoso> | These may behave unexpectedly on unsorted lists. |
| 2022-10-05 19:13:05 +0200 | <ski> | > group "mississippi" |
| 2022-10-05 19:13:06 +0200 | <lambdabot> | ["m","i","ss","i","ss","i","pp","i"] |
| 2022-10-05 19:13:26 +0200 | <dminuoso> | Huh! |
| 2022-10-05 19:13:38 +0200 | <dminuoso> | I think `group` is just what I need to greatly simplify my IPv6 pretty printing algorith,/ |
| 2022-10-05 19:13:45 +0200 | <dminuoso> | Thanks for that. |
| 2022-10-05 19:14:16 +0200 | sm | is puzzled.. nubSort was created for a reason.. now their haddocks are about the same though |
| 2022-10-05 19:14:31 +0200 | <dminuoso> | sm: Different complexity |
| 2022-10-05 19:14:38 +0200 | <geekosaur> | because sorted lists are much, much faster and lower memory to nub |
| 2022-10-05 19:14:45 +0200 | <ski> | @src nub |
| 2022-10-05 19:14:45 +0200 | <lambdabot> | nub = nubBy (==) |
| 2022-10-05 19:14:45 +0200 | <lambdabot> | --OR |
| 2022-10-05 19:14:46 +0200 | <lambdabot> | nub l = go l [] |
| 2022-10-05 19:14:46 +0200 | <lambdabot> | where go [] _ = [] |
| 2022-10-05 19:14:46 +0200 | <lambdabot> | go (x:xs) ls |
| 2022-10-05 19:14:46 +0200 | <sm> | ok |
| 2022-10-05 19:14:47 +0200 | <lambdabot> | | x `elem` ls = go xs ls |
| 2022-10-05 19:14:48 +0200 | <dminuoso> | One is O(n^2), the other is O(n*log n) |
| 2022-10-05 19:14:49 +0200 | <lambdabot> | | otherwise = x : go xs (x:ls) |
| 2022-10-05 19:15:02 +0200 | <ski> | @src nubBy |
| 2022-10-05 19:15:03 +0200 | <lambdabot> | nubBy eq [] = [] |
| 2022-10-05 19:15:03 +0200 | <lambdabot> | nubBy eq (x:xs) = x : nubBy eq (filter (\ y -> not (eq x y)) xs) |
| 2022-10-05 19:15:16 +0200 | <dminuoso> | And technically you could do ordNub it in O(n) |
| 2022-10-05 19:15:17 +0200 | Kaiepi | (~Kaiepi@142.68.249.28) (Quit: Leaving) |
| 2022-10-05 19:16:06 +0200 | <dminuoso> | Alternatively you can just handroll the thing, and scan characters with a Set remembering which characters you have seen already |
| 2022-10-05 19:16:31 +0200 | <EvanR> | yeah nub does what it says on the tin |
| 2022-10-05 19:16:44 +0200 | <EvanR> | ok maybe not, but there are no gotchas like group |
| 2022-10-05 19:17:11 +0200 | kdaishi | (~Thunderbi@94.191.153.178.mobile.tre.se) |
| 2022-10-05 19:17:16 +0200 | <EvanR> | I appreciate nub not using a word you probably want to use at some point |
| 2022-10-05 19:17:30 +0200 | <sm> | thanks, I must have been confused |
| 2022-10-05 19:17:30 +0200 | <sm> | so if I don't mind it getting sorted, nubSort is always more efficient eh |
| 2022-10-05 19:17:35 +0200 | goig | (~goig@202.91.42.7) (Quit: Client closed) |
| 2022-10-05 19:17:45 +0200 | <geekosaur> | not always |
| 2022-10-05 19:17:51 +0200 | <dminuoso> | It also sorts first |
| 2022-10-05 19:17:55 +0200 | zaquest | (~notzaques@5.130.79.72) (Ping timeout: 268 seconds) |
| 2022-10-05 19:17:57 +0200 | <dminuoso> | That may not be desirable |
| 2022-10-05 19:18:09 +0200 | <geekosaur> | we use nub in xmonad because if the list in question has more than 3 items in it, you;re making much worse mistakes than using nub 🙂 |
| 2022-10-05 19:18:12 +0200 | <sm> | nub also sorts ? |
| 2022-10-05 19:18:15 +0200 | <dminuoso> | But honestly, you can also just nub via a Set *directly* then |
| 2022-10-05 19:18:17 +0200 | <geekosaur> | and nubOrd would cost more to use |
| 2022-10-05 19:18:22 +0200 | <dminuoso> | Which is likely faster than nubOrd |
| 2022-10-05 19:18:27 +0200 | <geekosaur> | nubOrd does |
| 2022-10-05 19:18:41 +0200 | <geekosaur> | nub doesn;t and that;s why it's O(n*2) |
| 2022-10-05 19:18:42 +0200 | <dminuoso> | that is `Data.Set.toList . Data.Set.fromList` is very available |
| 2022-10-05 19:18:50 +0200 | <dminuoso> | If you dont care about being ordered along the way |
| 2022-10-05 19:18:54 +0200 | <geekosaur> | er n*n |
| 2022-10-05 19:19:11 +0200 | <geekosaur> | er something, I'm tired and not straight thinking |
| 2022-10-05 19:20:34 +0200 | <geekosaur> | n^2, bleh |
| 2022-10-05 19:20:57 +0200 | Erez | (~Erez@h-155-4-187-85.A980.priv.bahnhof.se) (Remote host closed the connection) |
| 2022-10-05 19:20:58 +0200 | <sm> | I think nubSort is always more efficient than nub because O(n log n) < O(n^2) ? |
| 2022-10-05 19:21:14 +0200 | <dminuoso> | sm: again not necessarily |
| 2022-10-05 19:21:21 +0200 | <sm> | how so ? |
| 2022-10-05 19:21:41 +0200 | <dminuoso> | You have different complexities. worst case, best case, average case |
| 2022-10-05 19:21:47 +0200 | <sm> | oh because O is just a rough order-of ? |
| 2022-10-05 19:21:49 +0200 | <dminuoso> | On haddock you generally only see worst case |
| 2022-10-05 19:21:59 +0200 | <geekosaur> | yes, and ignores constant factors |
| 2022-10-05 19:22:00 +0200 | <dminuoso> | And also, complexity does not directly tell you whether its faster |
| 2022-10-05 19:22:02 +0200 | <dminuoso> | just how they scale |
| 2022-10-05 19:22:10 +0200 | <dminuoso> | https://gist.github.com/dminuoso/672f3e167ddce78be6945977ce9239ba |
| 2022-10-05 19:22:11 +0200 | <geekosaur> | the constant factor for nubOrd is larger than for nub |
| 2022-10-05 19:22:23 +0200 | <sm> | good, that helps.. thanks all |
| 2022-10-05 19:22:24 +0200 | <geekosaur> | hence my n>3 comment earlier |
| 2022-10-05 19:22:32 +0200 | <dminuoso> | sm: ^- I reckon this will generally perform best for unsorted, and for sorted I would expect roundtripping through Set to be fastest. |
| 2022-10-05 19:23:05 +0200 | <dminuoso> | On average data |
| 2022-10-05 19:23:35 +0200 | <dminuoso> | For nubSort you'd have to analyze the particular choice of a sorting algorithm |
| 2022-10-05 19:24:05 +0200 | <dminuoso> | Ah heh |
| 2022-10-05 19:24:06 +0200 | mixphix | (~cigsender@cpe9050ca1782b3-cm9050ca1782b0.sdns.net.rogers.com) (Ping timeout: 265 seconds) |
| 2022-10-05 19:24:11 +0200 | <dminuoso> | ordNub and ordNubOn are exactly that implementation |
| 2022-10-05 19:24:24 +0200 | ft | (~ft@p3e9bc57b.dip0.t-ipconnect.de) |
| 2022-10-05 19:24:34 +0200 | razetime | (~quassel@117.193.2.107) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-10-05 19:24:36 +0200 | <dminuoso> | And nubSort (both from GHC.Utils.Misc) is roundtripping via Set. |
| 2022-10-05 19:25:17 +0200 | <dminuoso> | sm: regarding sorting, it may not be well known that you can actually sort in linear time. |
| 2022-10-05 19:25:37 +0200 | darkstarx | (~darkstard@50.126.124.156) |
| 2022-10-05 19:25:52 +0200 | <EvanR> | citation needed |
| 2022-10-05 19:26:06 +0200 | <dminuoso> | https://hackage.haskell.org/package/discrimination |
| 2022-10-05 19:26:12 +0200 | <dminuoso> | https://di.ku.dk/hjemmesider/ansatte/henglein/papers/henglein2011a.pdf |
| 2022-10-05 19:26:15 +0200 | <EvanR> | (rather necessary prereqs needed) |
| 2022-10-05 19:26:44 +0200 | Erez | (~Erez@h-155-4-187-85.A980.priv.bahnhof.se) |
| 2022-10-05 19:26:48 +0200 | darkstardevx | (~darkstard@50.126.124.156) (Ping timeout: 264 seconds) |
| 2022-10-05 19:28:24 +0200 | Vajb | (~Vajb@2001:999:504:1841:9e47:1ec7:a52e:1d57) (Read error: Connection reset by peer) |
| 2022-10-05 19:29:20 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2022-10-05 19:29:30 +0200 | <dminuoso> | https://www.youtube.com/watch?v=cB8DapKQz-I is also a nice presentation by edward |
| 2022-10-05 19:30:17 +0200 | wonko | (~wjc@2a0e:1c80:11::50) |
| 2022-10-05 19:32:53 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a468d2ea4a9a1bd9f4b.dip0.t-ipconnect.de) |
| 2022-10-05 19:33:09 +0200 | <sm> | not well known by me, impressive! |
| 2022-10-05 19:33:23 +0200 | <sm> | they'll be sorting in constant time next |
| 2022-10-05 19:34:35 +0200 | <EvanR> | sorting in constant time is feasible, you just need the necessary prereqs |
| 2022-10-05 19:34:42 +0200 | <EvanR> | like, already sorted xD |
| 2022-10-05 19:37:44 +0200 | Erez | (~Erez@h-155-4-187-85.A980.priv.bahnhof.se) (Remote host closed the connection) |
| 2022-10-05 19:38:15 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-05 19:38:17 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-10-05 19:41:25 +0200 | <tdammers> | requirements engineering at its finest |
| 2022-10-05 19:42:05 +0200 | littlefinger | (~littlefin@pool-100-15-237-121.washdc.fios.verizon.net) |
| 2022-10-05 19:42:27 +0200 | ltlefnger | (~ltlefnger@pool-100-15-237-121.washdc.fios.verizon.net) |
| 2022-10-05 19:43:17 +0200 | zns | (~zns@c-24-56-246-176.customer.broadstripe.net) |
| 2022-10-05 19:44:46 +0200 | Kaiepi | (~Kaiepi@142.68.249.28) |
| 2022-10-05 19:48:01 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-10-05 19:49:58 +0200 | ltlefnger | (~ltlefnger@pool-100-15-237-121.washdc.fios.verizon.net) (Remote host closed the connection) |
| 2022-10-05 19:51:15 +0200 | erisco | (~erisco@d24-57-249-233.home.cgocable.net) (Ping timeout: 252 seconds) |
| 2022-10-05 19:51:40 +0200 | goig | (~goig@202.91.42.7) |
| 2022-10-05 19:51:57 +0200 | <goig> | ski "what do you mean by \eta(c) = 1',\mu(a b) = 1' ?" By taking the definition from Wikipedia |
| 2022-10-05 19:51:58 +0200 | <goig> | \eta : I \rightarrow M. \mu : M \otimes M \rightarrow M |
| 2022-10-05 19:54:30 +0200 | <dminuoso> | Okay, GHC is only able to produce around 3000 lines of diagnostics per second. This is too slow. |
| 2022-10-05 19:55:01 +0200 | <dminuoso> | Is there a way to make GHC stop on the first diagnostic for a given module? |
| 2022-10-05 19:55:27 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-10-05 19:55:40 +0200 | Erez | (~Erez@h-155-4-187-85.A980.priv.bahnhof.se) |
| 2022-10-05 19:56:21 +0200 | erisco | (~erisco@d24-57-249-233.home.cgocable.net) |
| 2022-10-05 19:57:22 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-10-05 19:57:56 +0200 | Vajb | (~Vajb@2001:999:504:1841:9e47:1ec7:a52e:1d57) |
| 2022-10-05 19:58:24 +0200 | vorpuni | (~pvorp@2001:861:3881:c690:19c6:ba20:2cd3:1ae7) |
| 2022-10-05 19:59:48 +0200 | <goig> | dminuoso Diagnostics? |
| 2022-10-05 20:00:06 +0200 | Erez | (~Erez@h-155-4-187-85.A980.priv.bahnhof.se) (Ping timeout: 252 seconds) |
| 2022-10-05 20:00:34 +0200 | kenran | (~user@user/kenran) |
| 2022-10-05 20:00:47 +0200 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) (Ping timeout: 252 seconds) |
| 2022-10-05 20:01:38 +0200 | king_gs | (~Thunderbi@2806:103e:29:5a6:d0be:f9c4:80c9:e8c5) |
| 2022-10-05 20:02:12 +0200 | zns | (~zns@c-24-56-246-176.customer.broadstripe.net) (Remote host closed the connection) |
| 2022-10-05 20:02:45 +0200 | zns | (~zns@c-24-56-246-176.customer.broadstripe.net) |
| 2022-10-05 20:03:06 +0200 | kenran` | (~user@user/kenran) |
| 2022-10-05 20:05:54 +0200 | goig | (~goig@202.91.42.7) (Quit: Client closed) |
| 2022-10-05 20:05:55 +0200 | kenran` | (~user@user/kenran) (Remote host closed the connection) |
| 2022-10-05 20:06:57 +0200 | Erez | (~Erez@h-155-4-187-85.A980.priv.bahnhof.se) |
| 2022-10-05 20:07:21 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.6) |
| 2022-10-05 20:08:31 +0200 | king_gs | (~Thunderbi@2806:103e:29:5a6:d0be:f9c4:80c9:e8c5) (Remote host closed the connection) |
| 2022-10-05 20:11:14 +0200 | <ski> | @tell goig but if `M' is a monad (which is an endofunctor, with some more stuff), then what does it mean to say `1' is an element of `M' ? and in this case, your `M \otimes M' is not a cartesian product, but a composition, so what sense could `\mu(a b)' possibly make ? |
| 2022-10-05 20:11:14 +0200 | <lambdabot> | Consider it noted. |
| 2022-10-05 20:11:53 +0200 | <zns> | is learn you a haskell still the top recommended entry point to haskell coming from a C background? |
| 2022-10-05 20:12:33 +0200 | <ski> | probably not .. or at least not on its own |
| 2022-10-05 20:13:08 +0200 | <ski> | (it has no exercises. and people have described it as a "four-hour long trailer", saying it doesn't go in-depth enough) |
| 2022-10-05 20:13:20 +0200 | <ski> | @where CIS194 |
| 2022-10-05 20:13:21 +0200 | <lambdabot> | https://www.seas.upenn.edu/~cis194/spring13/lectures.html |
| 2022-10-05 20:13:24 +0200 | <ski> | has exercises |
| 2022-10-05 20:13:27 +0200 | <zns> | ah ok, good to know - what's a common alternative |
| 2022-10-05 20:13:34 +0200 | <zns> | ah sweet |
| 2022-10-05 20:13:46 +0200 | <ski> | a real textbook might be nice |
| 2022-10-05 20:13:51 +0200 | <[exa]> | wiwinwlh is super useful |
| 2022-10-05 20:13:56 +0200 | <[exa]> | zns: https://github.com/sdiehl/wiwinwlh |
| 2022-10-05 20:14:12 +0200 | <ski> | like "Programming in Haskell", by Graham Hutton. or "Haskell: The Craft of Functional Programming", by Simon Thompson |
| 2022-10-05 20:14:31 +0200 | `2jt | (~jtomas@90.red-88-17-81.dynamicip.rima-tde.net) |
| 2022-10-05 20:14:40 +0200 | <zns> | ski: is the age of CIS194 going to be a problem? |
| 2022-10-05 20:14:49 +0200 | <ski> | i don't think so |
| 2022-10-05 20:15:13 +0200 | <ski> | (i think some people have said they prefer that specific year of the course to at least some later years) |
| 2022-10-05 20:15:32 +0200 | <ski> | RWH has probably aged less well |
| 2022-10-05 20:15:41 +0200 | <ski> | @where wikibook |
| 2022-10-05 20:15:42 +0200 | <lambdabot> | http://en.wikibooks.org/wiki/Haskell |
| 2022-10-05 20:15:47 +0200 | <ski> | @where HTaC |
| 2022-10-05 20:15:47 +0200 | <lambdabot> | "Haskell Tutorial and Cookbook" by Mark Watson in 2017-09-04 at <https://leanpub.com/haskell-cookbook> |
| 2022-10-05 20:15:51 +0200 | <ski> | might also be useful |
| 2022-10-05 20:16:00 +0200 | <EvanR> | @where gentle |
| 2022-10-05 20:16:01 +0200 | <lambdabot> | http://www.haskell.org/tutorial/ |
| 2022-10-05 20:16:11 +0200 | <EvanR> | can't beat that URL |
| 2022-10-05 20:16:31 +0200 | <ski> | the "Gentle" one assumes you already know some principles of functional programming, say coming from Scheme or one of the MLs |
| 2022-10-05 20:16:44 +0200 | <EvanR> | though you could beat that style sheet |
| 2022-10-05 20:17:19 +0200 | <zns> | yeah this shall be my first real intro to FP stuff, i'm mostly in the realm of embedded c / asm |
| 2022-10-05 20:17:27 +0200 | <ski> | zns : it also helps to ask e.g. in here, when you've got questions, or want advice or go stuck on something |
| 2022-10-05 20:17:49 +0200 | <ski> | nice :) |
| 2022-10-05 20:17:56 +0200 | <zns> | yeah already I've noticed how more active and helpful #haskell is than some channels for other languages lol |
| 2022-10-05 20:18:41 +0200 | <dminuoso> | zns: Note, that a few CIS194 2016 code bits dont work anymore because the underlying library has been updated. Its nothing minor, this place should be able to help you out. |
| 2022-10-05 20:18:48 +0200 | <dminuoso> | *it nothing major! |
| 2022-10-05 20:19:09 +0200 | <dminuoso> | Probably should poke Joachim to get some updates in |
| 2022-10-05 20:19:22 +0200 | <dminuoso> | Maybe when I meet him at Haskell eXchange |
| 2022-10-05 20:19:24 +0200 | <ski> | (there's also a #haskell-beginners channel. but beginners questions are also welcome in here. the main difference between the channels is that in here it's sometimes more noisy (and so you might then prefer the other one, to have a more focused conversation), while the other one doesn't have as many people, so you're commonly more likely to get someone responding sooner, in here) |
| 2022-10-05 20:19:34 +0200 | <zns> | this wiwinwlh looks like a pretty nice resource, seems like I'll need to make html it myself though |
| 2022-10-05 20:19:53 +0200 | <zns> | ah good to know ski, ill make sure to add that to my alias |
| 2022-10-05 20:20:31 +0200 | <[exa]> | zns: oh noes the site is down |
| 2022-10-05 20:20:42 +0200 | <[exa]> | zns: you might archive.org it |
| 2022-10-05 20:21:37 +0200 | <[exa]> | actually lemme build that |
| 2022-10-05 20:21:49 +0200 | shriekingnoise | (~shrieking@186.137.167.202) |
| 2022-10-05 20:21:55 +0200 | <zns> | yeah i was just going to make it myself since they got the makefile all setup |
| 2022-10-05 20:24:09 +0200 | <ski> | zns : oh .. you should expect to have to unlearn and relearn quite a bit. learning a different programming paradigm is a bit like learning to program from scratch, all over again |
| 2022-10-05 20:24:43 +0200 | <ski> | obviously things do carry over. but it's better to come at it from a mindset not expecting it to be like learning yet another imperative language |
| 2022-10-05 20:26:27 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-05 20:26:59 +0200 | AlexZenon | (~alzenon@94.233.240.222) (Ping timeout: 268 seconds) |
| 2022-10-05 20:27:25 +0200 | zns | (~zns@c-24-56-246-176.customer.broadstripe.net) (Quit: ) |
| 2022-10-05 20:27:55 +0200 | Alex_test | (~al_test@94.233.240.222) (Ping timeout: 252 seconds) |
| 2022-10-05 20:28:26 +0200 | <[exa]> | btw is sdiehl taking care of the repo anymore or did it evolve towards another maintainer? |
| 2022-10-05 20:28:36 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a468d2ea4a9a1bd9f4b.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2022-10-05 20:29:56 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-10-05 20:30:40 +0200 | AlexZenon | (~alzenon@94.233.240.222) |
| 2022-10-05 20:32:32 +0200 | finsternis | (~X@23.226.237.192) (Read error: Connection reset by peer) |
| 2022-10-05 20:32:39 +0200 | zane_ | (~zane@c-24-56-246-176.customer.broadstripe.net) |
| 2022-10-05 20:32:41 +0200 | Alex_test | (~al_test@94.233.240.222) |
| 2022-10-05 20:32:42 +0200 | <zane_> | quit |
| 2022-10-05 20:32:45 +0200 | zane_ | (~zane@c-24-56-246-176.customer.broadstripe.net) (Client Quit) |
| 2022-10-05 20:34:00 +0200 | zns | (~zns@c-24-56-246-176.customer.broadstripe.net) |
| 2022-10-05 20:38:36 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 20:39:05 +0200 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-10-05 20:39:16 +0200 | finsternis | (~X@23.226.237.192) |
| 2022-10-05 20:43:01 +0200 | vglfr | (~vglfr@145.224.100.190) (Read error: Connection reset by peer) |
| 2022-10-05 20:43:25 +0200 | vglfr | (~vglfr@145.224.100.190) |
| 2022-10-05 20:44:37 +0200 | zns | (~zns@c-24-56-246-176.customer.broadstripe.net) (Changing host) |
| 2022-10-05 20:44:37 +0200 | zns | (~zns@user/zns) |
| 2022-10-05 20:44:56 +0200 | <dminuoso> | Realistically, how portable will using "/" as a path separator be? |
| 2022-10-05 20:45:25 +0200 | <dminuoso> | It seems like Linux, *BSD, macOS should be fine. So what about WindowS? |
| 2022-10-05 20:47:41 +0200 | <geekosaur> | windows appears to still support it in function calls. not at the command line though |
| 2022-10-05 20:47:57 +0200 | <geekosaur> | and I don't know what guarantees there are on it continuing to work |
| 2022-10-05 20:48:17 +0200 | simendsjo | (~user@84.211.91.241) |
| 2022-10-05 20:50:25 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-05 20:51:17 +0200 | <EvanR> | how many battle ships would halt and catch fire, or missiles explode early if suddenly a windows update came in which invalidated / in paths |
| 2022-10-05 20:51:24 +0200 | <sm> | I would expect it to always work when using the directory/filepath libs ? |
| 2022-10-05 20:51:39 +0200 | <dminuoso> | Yes, and I dont want to use them. |
| 2022-10-05 20:51:57 +0200 | <dminuoso> | Im trying very hard to completely minimize the build-depends footprint here |
| 2022-10-05 20:52:17 +0200 | <sm> | I see. I thought it did work find at windows command prompts also |
| 2022-10-05 20:52:41 +0200 | <sm> | fine |
| 2022-10-05 20:53:00 +0200 | <dminuoso> | What if they run via services.msc? |
| 2022-10-05 20:53:39 +0200 | pavonia | (~user@user/siracusa) |
| 2022-10-05 20:53:41 +0200 | <geekosaur> | hm. trawling the windows online docs, only \ is documented as a path component separator, but / is still a reserved character according to https://learn.microsoft.com/en-us/windows/win32/intl/character-sets-used-in-file-names?source=reco… |
| 2022-10-05 20:53:50 +0200 | <zns> | is there a preference between stack & cabal? or are they used for different purposes? |
| 2022-10-05 20:54:11 +0200 | <zns> | i was going to build wiwinwlh and it seems you can either stack install or cabal install it |
| 2022-10-05 20:54:11 +0200 | <geekosaur> | they both do pretty much the same thing these days, just in slightly different ways |
| 2022-10-05 20:54:24 +0200 | <geekosaur> | some of us prefer cabal, others stack |
| 2022-10-05 20:54:39 +0200 | <geekosaur> | but these days it doesn't really matter a whole lot |
| 2022-10-05 20:54:50 +0200 | <zns> | hm, interesting..and confusing haha |
| 2022-10-05 20:55:02 +0200 | <sm> | some things are a little easier with stack. Some projects will be easier to get building with one or the other |
| 2022-10-05 20:55:16 +0200 | <dminuoso> | Im going to just take a chance here, its only a list of hard-wired paths executed at TH time, relative to the build directory. |
| 2022-10-05 20:55:20 +0200 | stackdroid18 | (~stackdroi@user/stackdroid) |
| 2022-10-05 20:55:33 +0200 | <zns> | I assume they probably worked it out so they don't conflict if you have both installed? |
| 2022-10-05 20:55:36 +0200 | <dminuoso> | So Ill just blindly assume `BS.readFile foo/bar` will work, given that it should work at the prompt |
| 2022-10-05 20:55:49 +0200 | <dminuoso> | Hooray, no need for `filepath` :) |
| 2022-10-05 20:55:51 +0200 | <sm> | zns, yes |
| 2022-10-05 20:56:36 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2022-10-05 20:57:10 +0200 | <zns> | ah I see theres a rustup-adjacent sort of tool ghcup |
| 2022-10-05 20:57:11 +0200 | coot | (~coot@213.134.171.3) (Quit: coot) |
| 2022-10-05 20:57:26 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-10-05 20:58:47 +0200 | <EvanR> | ghcup rocks |
| 2022-10-05 20:59:08 +0200 | <EvanR> | screw distro package managers |
| 2022-10-05 21:00:22 +0200 | <telser_> | I definitely want package managers |
| 2022-10-05 21:00:38 +0200 | infinity0 | (~infinity0@185.112.146.113) (Remote host closed the connection) |
| 2022-10-05 21:01:01 +0200 | <sm> | zns: looking at https://github.com/sdiehl/wiwinwlh, personally I would try cabal first as it will use your currently installed default ghc and things might just build. If they don't, the you could stack which will install the old GHC version specified in stack.yaml - filling up your disk a bit but relatively sure to just work |
| 2022-10-05 21:01:10 +0200 | <telser_> | Does anyone know why hls doesn't have an ubuntu20.04 flavor like ghc does? |
| 2022-10-05 21:02:42 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 21:02:45 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:880f:f8ae:6077:ffec) |
| 2022-10-05 21:02:58 +0200 | califax | (~califax@user/califx) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-10-05 21:03:44 +0200 | califax | (~califax@user/califx) |
| 2022-10-05 21:04:49 +0200 | infinity0 | (~infinity0@185.112.146.113) |
| 2022-10-05 21:04:54 +0200 | ulvarrefr | (~user@188.124.56.153) |
| 2022-10-05 21:05:44 +0200 | littlefinger | (~littlefin@pool-100-15-237-121.washdc.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2022-10-05 21:06:10 +0200 | <ski> | zns : <https://gist.github.com/merijn/8152d561fb8b011f9313c48d876ceb07> might be interesting |
| 2022-10-05 21:06:27 +0200 | <zns> | just read through that! thanks though ski |
| 2022-10-05 21:09:20 +0200 | <zns> | thoughts on https://github.com/haskell-beginners-2022/course-plan ? |
| 2022-10-05 21:09:47 +0200 | RosarioPulella[m | (~rosariopu@2001:470:69fc:105::a57) |
| 2022-10-05 21:10:56 +0200 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) (Ping timeout: 260 seconds) |
| 2022-10-05 21:12:20 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-05 21:13:13 +0200 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) |
| 2022-10-05 21:15:50 +0200 | zns | (~zns@user/zns) (Quit: zzz) |
| 2022-10-05 21:17:26 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-05 21:17:39 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-10-05 21:18:01 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-05 21:18:04 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-10-05 21:18:57 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-10-05 21:18:58 +0200 | kuribas | (~user@ptr-17d51eouflh02xad3po.18120a2.ip6.access.telenet.be) |
| 2022-10-05 21:20:24 +0200 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 2022-10-05 21:22:22 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a468d2ea4a9a1bd9f4b.dip0.t-ipconnect.de) |
| 2022-10-05 21:23:37 +0200 | ubert | (~Thunderbi@178.165.179.119.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2022-10-05 21:28:00 +0200 | lottaquestions | (~nick@2607:fa49:503e:7100:aef6:98d:3d4f:a599) |
| 2022-10-05 21:31:38 +0200 | zns | (~zns@user/zns) |
| 2022-10-05 21:46:53 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2022-10-05 21:48:12 +0200 | zns | (~zns@user/zns) (Quit: zzz) |
| 2022-10-05 21:49:16 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-10-05 21:51:10 +0200 | Everything | (~Everythin@37.115.210.35) |
| 2022-10-05 21:53:28 +0200 | loras | (~bc@c-73-139-125-125.hsd1.fl.comcast.net) (Quit: Leaving) |
| 2022-10-05 21:53:47 +0200 | Guest112009 | (~bc@c-73-139-125-125.hsd1.fl.comcast.net) |
| 2022-10-05 21:54:13 +0200 | Guest112009 | loras |
| 2022-10-05 21:56:29 +0200 | bc_ | (~bc@c-73-139-125-125.hsd1.fl.comcast.net) |
| 2022-10-05 21:56:51 +0200 | loras | (~bc@c-73-139-125-125.hsd1.fl.comcast.net) (Client Quit) |
| 2022-10-05 21:56:51 +0200 | bc_ | (~bc@c-73-139-125-125.hsd1.fl.comcast.net) (Client Quit) |
| 2022-10-05 21:57:10 +0200 | loras | (~bc@c-73-139-125-125.hsd1.fl.comcast.net) |
| 2022-10-05 21:58:23 +0200 | loras | (~bc@c-73-139-125-125.hsd1.fl.comcast.net) (Client Quit) |
| 2022-10-05 21:59:05 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-34.elisa-laajakaista.fi) |
| 2022-10-05 22:08:54 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-10-05 22:09:10 +0200 | Erez | (~Erez@h-155-4-187-85.A980.priv.bahnhof.se) (Remote host closed the connection) |
| 2022-10-05 22:09:28 +0200 | Erez | (~Erez@155.4.187.85) |
| 2022-10-05 22:10:16 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-10-05 22:10:54 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-10-05 22:11:30 +0200 | lyle | (~lyle@104.246.145.85) (Quit: WeeChat 3.6) |
| 2022-10-05 22:13:56 +0200 | Erez | (~Erez@155.4.187.85) (Ping timeout: 252 seconds) |
| 2022-10-05 22:14:59 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-10-05 22:16:10 +0200 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 246 seconds) |
| 2022-10-05 22:17:02 +0200 | zns | (~zns@user/zns) |
| 2022-10-05 22:18:45 +0200 | zns | (~zns@user/zns) (Client Quit) |
| 2022-10-05 22:21:31 +0200 | erisco | (~erisco@d24-57-249-233.home.cgocable.net) (Ping timeout: 260 seconds) |
| 2022-10-05 22:22:32 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-05 22:26:58 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-10-05 22:28:31 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 260 seconds) |
| 2022-10-05 22:32:58 +0200 | erisco | (~erisco@d24-57-249-233.home.cgocable.net) |
| 2022-10-05 22:34:47 +0200 | Erez | (~Erez@h-155-4-187-85.A980.priv.bahnhof.se) |
| 2022-10-05 22:35:16 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:880f:f8ae:6077:ffec) (Remote host closed the connection) |
| 2022-10-05 22:35:52 +0200 | rockystone | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-05 22:40:52 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:880f:f8ae:6077:ffec) |
| 2022-10-05 22:44:41 +0200 | simendsjo | (~user@84.211.91.241) (Ping timeout: 252 seconds) |
| 2022-10-05 22:48:19 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2022-10-05 22:49:36 +0200 | Erez | (~Erez@h-155-4-187-85.A980.priv.bahnhof.se) (Remote host closed the connection) |
| 2022-10-05 22:49:54 +0200 | Erez | (~Erez@h-155-4-187-85.A980.priv.bahnhof.se) |
| 2022-10-05 22:51:44 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2022-10-05 22:52:41 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-10-05 22:53:33 +0200 | jakalx | (~jakalx@base.jakalx.net) () |
| 2022-10-05 22:54:07 +0200 | rockystone | (~rocky@user/rockymarine) |
| 2022-10-05 22:55:10 +0200 | gqplox | (~textual@97e654ef.skybroadband.com) |
| 2022-10-05 22:56:55 +0200 | codaraxis___ | (~codaraxis@user/codaraxis) |
| 2022-10-05 23:00:05 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-10-05 23:00:33 +0200 | codaraxis__ | (~codaraxis@user/codaraxis) (Ping timeout: 268 seconds) |
| 2022-10-05 23:01:59 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-10-05 23:02:15 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-10-05 23:05:30 +0200 | chomwitt | (~chomwitt@2a02:587:dc14:f500:d53b:b7dd:b89c:482e) (Ping timeout: 268 seconds) |
| 2022-10-05 23:06:48 +0200 | zns | (~zns@user/zns) |
| 2022-10-05 23:07:38 +0200 | zer0bitz | (~zer0bitz@2001:2003:f748:2000:8816:b288:20c9:6a7a) (Read error: Connection reset by peer) |
| 2022-10-05 23:08:57 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:463c:6245:cbff:fe9f:48b1) |
| 2022-10-05 23:11:12 +0200 | justache | justHaunted |
| 2022-10-05 23:12:25 +0200 | erisco | (~erisco@d24-57-249-233.home.cgocable.net) (Ping timeout: 250 seconds) |
| 2022-10-05 23:15:29 +0200 | zns | (~zns@user/zns) (Quit: zzz) |
| 2022-10-05 23:15:40 +0200 | erisco | (~erisco@d24-57-249-233.home.cgocable.net) |
| 2022-10-05 23:16:01 +0200 | euandreh | (~euandreh@179.214.113.107) (Ping timeout: 246 seconds) |
| 2022-10-05 23:16:42 +0200 | zns | (~zns@user/zns) |
| 2022-10-05 23:17:09 +0200 | euandreh | (~euandreh@179.214.113.107) |
| 2022-10-05 23:17:23 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a468d2ea4a9a1bd9f4b.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2022-10-05 23:20:49 +0200 | Erez | (~Erez@h-155-4-187-85.A980.priv.bahnhof.se) (Remote host closed the connection) |
| 2022-10-05 23:21:59 +0200 | Erez | (~Erez@h-155-4-187-85.A980.priv.bahnhof.se) |
| 2022-10-05 23:26:10 +0200 | Erez | (~Erez@h-155-4-187-85.A980.priv.bahnhof.se) (Ping timeout: 252 seconds) |
| 2022-10-05 23:31:15 +0200 | kmein | (~weechat@user/kmein) (Quit: ciao kakao) |
| 2022-10-05 23:31:27 +0200 | zns | (~zns@user/zns) (Quit: zzz) |
| 2022-10-05 23:33:18 +0200 | kmein | (~weechat@user/kmein) |
| 2022-10-05 23:38:04 +0200 | Erez | (~Erez@h-155-4-187-85.A980.priv.bahnhof.se) |
| 2022-10-05 23:42:26 +0200 | jonathanx_ | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) |
| 2022-10-05 23:42:27 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) (Read error: Connection reset by peer) |
| 2022-10-05 23:43:09 +0200 | talismanick | (~talismani@2601:200:c100:c9e0::24ac) (Ping timeout: 268 seconds) |
| 2022-10-05 23:43:35 +0200 | dequbed | (~dequbed@banana-new.kilobyte22.de) (Quit: bye!) |
| 2022-10-05 23:48:35 +0200 | dequbed | (~dequbed@banana-new.kilobyte22.de) |
| 2022-10-05 23:50:53 +0200 | michalz | (~michalz@185.246.207.203) (Remote host closed the connection) |
| 2022-10-05 23:53:46 +0200 | zns | (~zns@user/zns) |
| 2022-10-05 23:54:25 +0200 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) (Remote host closed the connection) |
| 2022-10-05 23:55:24 +0200 | ddellacosta | (~ddellacos@143.244.47.86) |
| 2022-10-05 23:56:36 +0200 | Erez | (~Erez@h-155-4-187-85.A980.priv.bahnhof.se) (Ping timeout: 252 seconds) |
