Newest at the top
2025-03-28 14:17:21 +0100 | <jacopovalanzano> | o/ |
2025-03-28 14:17:18 +0100 | jacopovalanzano | (~jacopoval@cpc151911-cove17-2-0-cust105.3-1.cable.virginm.net) |
2025-03-28 14:13:53 +0100 | <tomsmeding> | not unlikely that for arrays, allocating the array itself outside of the GC'd heap would be counterproductive, because if it's a boxed array then you'd have to register all the contained pointers as additional GC roots anyway, and it's not boxed then the GC spends only O(1) time on it |
2025-03-28 14:12:56 +0100 | malte | (~malte@mal.tc) (Ping timeout: 244 seconds) |
2025-03-28 14:12:52 +0100 | <tomsmeding> | ^ |
2025-03-28 14:12:41 +0100 | <Leary> | __monty__: GHC doesn't do any magic for you, it gives you the tools to create safe interfaces over your own manually allocated/freed data. |
2025-03-28 14:11:15 +0100 | <tomsmeding> | but indeed the strict linearity is inessential |
2025-03-28 14:11:06 +0100 | <tomsmeding> | as in: you do get the advantage that the array can be used outside of IO or ST |
2025-03-28 14:10:54 +0100 | <tomsmeding> | __monty__: I think for this module, it's indeed smoke and mirrors, as you say |
2025-03-28 14:10:01 +0100 | <yahb2> | foo ; :: forall a b (p :: GHC.Types.Multiplicity). ; (a %p -> b) -> a %p -> b |
2025-03-28 14:10:01 +0100 | <tomsmeding> | % :t foo |
2025-03-28 14:09:58 +0100 | <yahb2> | <no output> |
2025-03-28 14:09:58 +0100 | <tomsmeding> | % :seti -fprint-explicit-foralls |
2025-03-28 14:09:56 +0100 | <__monty__> | Is it still all smoke and mirrors or does linear data actually get allocated/freed outside of the GCed memory? |
2025-03-28 14:09:55 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
2025-03-28 14:09:39 +0100 | <yahb2> | <no output> |
2025-03-28 14:09:39 +0100 | <tomsmeding> | % foo :: forall a b p. (a %p-> b) -> a %p-> b ; foo g x = g x |
2025-03-28 14:09:31 +0100 | <yahb2> | <no output> |
2025-03-28 14:09:31 +0100 | <tomsmeding> | % :seti -XLinearTypes |
2025-03-28 14:09:12 +0100 | <tomsmeding> | __monty__: I suggest you peruse this page :) https://hackage.haskell.org/package/linear-base-0.4.0/docs/Data-Array-Mutable-Linear.html#v:get |
2025-03-28 14:08:53 +0100 | <tomsmeding> | oh, apparently ghc does support multiplicity polymorphism |
2025-03-28 14:08:22 +0100 | <__monty__> | How about array indexing? It'd be pretty inconvenient if that had to free the array. |
2025-03-28 14:08:01 +0100 | <tomsmeding> | originally the syntax allowed multiplicity polymorphism, where you could have `forall p. a %p-> b`, but IIRC ghc doesn't currently implement that or something |
2025-03-28 14:07:20 +0100 | <tomsmeding> | or hell, if you don't want letters in a symbol, do -%> or something |
2025-03-28 14:07:04 +0100 | <__monty__> | Yeah, bring back the lollipop. |
2025-03-28 14:06:35 +0100 | <tomsmeding> | (I hate the visuals of that %1-> syntax.) |
2025-03-28 14:06:25 +0100 | <tomsmeding> | er, `toList :: Array a %1-> [a]`, of course |
2025-03-28 14:06:16 +0100 | <tomsmeding> | though sometimes it comes in a different guise, like `toList :: Array a -> [a]` |
2025-03-28 14:05:57 +0100 | <tomsmeding> | for arrays, kind of? |
2025-03-28 14:05:53 +0100 | <tomsmeding> | well, that depends on the API |
2025-03-28 14:05:32 +0100 | <tomsmeding> | I guess with affine arrows you can still opt-in to explicit consumption as the user, but with linear arrows, the API designer can _require_ explicit consumption |
2025-03-28 14:05:30 +0100 | <__monty__> | And `free` is the only possible operation that consumes consumes an array without producing one? |
2025-03-28 14:04:52 +0100 | <tomsmeding> | in that sense, linear arrows are "more general": they allow expressing safe APIs for more kinds of resources (i.e. ones that need to be closed/freed/... -- i.e. "consumed" -- at a predictable time) |
2025-03-28 14:04:49 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) (Ping timeout: 260 seconds) |
2025-03-28 14:03:41 +0100 | <tomsmeding> | __monty__: if you require linearity, you can use linear types as a memory management system. Opened files need to be closed, allocated arrays need to be freed; if you have affine arrows only, you still need a GC to clean them up |
2025-03-28 14:01:18 +0100 | <vpan> | thanks for the hints. The trick using `Ap` looks cool. :) |
2025-03-28 13:58:44 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
2025-03-28 13:57:37 +0100 | weary-traveler | (~user@user/user363627) user363627 |
2025-03-28 13:57:30 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) |
2025-03-28 13:54:55 +0100 | <lambdabot> | forall k (t :: * -> *) (f :: k -> *) (a1 :: k) a2. (Foldable t, Monoid (Ap f a1)) => (a2 -> f a1) -> t a2 -> f a1 |
2025-03-28 13:54:54 +0100 | <Leary> | :t (getAp .) . foldMap . (Ap .) |
2025-03-28 13:54:45 +0100 | <__monty__> | That does seem similar. |
2025-03-28 13:54:37 +0100 | <lambdabot> | Data.Vector.Fusion.Stream.Monadic foldrM :: Monad m => (a -> b -> m b) -> b -> Stream m a -> m b |
2025-03-28 13:54:37 +0100 | <lambdabot> | Data.Vector.Fusion.Bundle.Monadic foldrM :: Monad m => (a -> b -> m b) -> b -> Bundle m v a -> m b |
2025-03-28 13:54:37 +0100 | <lambdabot> | Data.Foldable foldrM :: (Foldable t, Monad m) => (a -> b -> m b) -> b -> t a -> m b |
2025-03-28 13:54:36 +0100 | <__monty__> | @hoogle foldrM |
2025-03-28 13:52:50 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
2025-03-28 13:51:03 +0100 | <__monty__> | I think the reason not to use the GHC modules is the size of the package. |
2025-03-28 13:48:21 +0100 | <vpan> | hi, `foldMapM` from GHC.Utils.Monad seems useful (found it on hoogle), but calling something from the compiler's namespace feels wrong. There must be a reason those functions aren't in base. Is my intuition correct that typical applications (that don't process Haskell code) should stay away from GHC.*? |
2025-03-28 13:48:06 +0100 | zungi | (~tory@user/andrewchawk) andrewchawk |