2025/03/28

Newest at the top

2025-03-28 14:17:21 +0100 <jacopovalanzano> o/
2025-03-28 14:17:18 +0100jacopovalanzano(~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 +0100malte(~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 +0100JuanDaugherty(~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 +0100hattckory(~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 +0100chele(~chele@user/chele) (Remote host closed the connection)
2025-03-28 13:57:37 +0100weary-traveler(~user@user/user363627) user363627
2025-03-28 13:57:30 +0100hattckory(~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 +0100Unicorn_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 +0100zungi(~tory@user/andrewchawk) andrewchawk